randy1
October 24, 2022, 12:08pm
#1
Hi,
I’m currently trying to compile my code using the following settings
DEBUG: Current (stlink) On-board (stlink) External (blackmagic, cmsis-dap, jlink)
PACKAGES:
- framework-mbed @ 6.60600.201227 (6.6.0)
- tool-dfuutil @ 1.11.0
- tool-openocd @ 2.1100.211028 (11.0)
- tool-stm32duino @ 1.0.2
- toolchain-gccarmnoneeabi @ 1.90201.191206 (9.2.1)
My environment looks like that:
[env:debug]
build_type = debug
platform = ststm32
board = nucleo_l476rg
framework = mbed
monitor_speed = 115200
build_flags =
-std=gnu++2a
-std=c++2a
build_unflags =
-fno-rtti
-std=gnu++11
However, new c++17 and c++20 features don’t get compiled (error messages for c++17/c++20 types during compilation). How can I change that?
Thank you,
What minimal source code are you using to test this C++20 feature?
randy1
October 24, 2022, 7:25pm
#3
Currently, the only line that requires c++ 17 is
static constexpr std::string_view VALUE= "Value";
which gets me the following error during compilation
error: 'string_view' in namespace 'std' does not name a type
Works.
Make sure you have all latest versions: CLI → pio pkg update -g -p ststm32, and my platformio.ini.
randy1
October 26, 2022, 2:44pm
#5
Thank you very much! It works now. Might have been the -std=gnu++14 instead of -std::gnu++11 under unbuild_flags.
mark-81
October 28, 2022, 7:48am
#6
Sorry to hijack this thread but I have a similar problem:
CLI update
pio pkg update -g -p espressif32
Platform Manager: espressif32@5.2.0 is already up-to-date
Tool Manager: framework-arduinoespressif32@3.20005.220925 is already up-to-date
Tool Manager: tool-esptoolpy@1.40201.0 is already up-to-date
Tool Manager: tool-mkfatfs@2.0.1 is already up-to-date
Tool Manager: tool-mklittlefs@1.203.210628 is already up-to-date
Tool Manager: tool-mkspiffs@2.230.0 is already up-to-date
Tool Manager: tool-openocd-esp32@2.1100.20220706 is already up-to-date
Tool Manager: toolchain-xtensa-esp32@8.4.0+2021r2-patch3 is already up-to-date
platformio.ini
build_unflags =
-std=gnu++14
build_flags =
-D"TEMPLATE_PLACEHOLDER=126"
-D_IR_ENABLE_DEFAULT_=false
-DDECODE_NEC=true
-Os
-DCORE_DEBUG_LEVEL=0
-std=gnu++2a
Test file
#define LED_SIZE 113
#define SEGMENT_SIZE 3
constexpr int LED_SEGMENTS[SEGMENT_SIZE] = {30, 70, 13};
static_assert(std::accumulate(std::begin(LED_SEGMENTS), std::end(LED_SEGMENTS), 0) == LED_SIZE);
Build errors
include/common.h:74:20: error: 'accumulate' is not a member of 'std'
include/common.h:74:36: error: 'begin' is not a member of 'std'
include/common.h:74:62: error: 'end' is not a member of 'std'
That’s a nope from the latest compiler. std::accumulate is not constexpr.
https://godbolt.org/z/8bqjTczTb
On x64 G++, compiler versions 8.x all fail to compile that code, same with 9.x Only 10.x and upwards are able to compile that. The XTensa GCC/G++ toolchain is based on 8.4.3. If you want this fixed, ask Espressif to upgrade their XTensa compiler codebase and rerelease it.
Interesting, Releases · espressif/crosstool-NG · GitHub does have a GCC 11.2.0 based release after all, but it’s not used in Arduino or ESP-IDF.
When I download https://github.com/espressif/crosstool-NG/releases/download/esp-2022r1/xtensa-esp32-elf-gcc11_2_0-esp-2022r1-win64.zip , unzip it, add a package.json of
{
"name": "toolchain-xtensa-esp32",
"version": "11.2.0+2022r1",
"description": "GCC Toolchain for Espressif ESP32 Xtensa MCUs",
"keywords": [
"build tools",
"compiler",
"assembler",
"linker",
"preprocessor",
"espressif",
"esp32"
],
"license": "GPL-2.0-or-later",
"repository": {
"type": "git",
"url": "https://github.com/espressif/crosstool-NG"
},
"system": "windows_amd64"
}
and do my platformio.ini as
[env:esp32]
platform = espressif32
board = esp32dev
framework = arduino
build_unflags =
-std=gnu++11
build_flags =
-std=gnu++2a
platform_packages =
toolchain-xtensa-esp32@symlink://C:\Users\Max\Downloads\xtensa-esp32-elf-gcc11_2_0-esp-2022r1-win64\xtensa-esp32-elf
It does compile.
But that’s incredibly insane just to get a const-expression std::accumulate to work, I would not recommend that to anyone. Something simpler or custom may work on the regular toolchain version too.
1 Like
This might be relevant for using any C++20 features supported by gcc 11.2. Any updates on pushing this toolchain to the registry?
