This is the third version of this patch series. Changes from v2:
* Change the default value of the new --enable-multilib-space option to disabled. I didn't catch this regression because I was only testing with the new option enabled. The Linaro regression tests identified the issue. ---- Description of the V3 series ---- When building toolchains for embedded development, some projects will want to optimize for speed while others are much more concerned about overall code size. We can do this using the existing GCC multilib infrastructure, adding suitable speed and size variants as another dimension of the multilib table. This could replace the current Debian arm-none-eabi toolchain practice of duplicating the C library build into 'regular' and 'release' variants and then requiring application developers select which to use with a new GCC flag, --picolibc-buildtype=release, which is processed in a custom .specs file. This mechanism only provides space/speed optimized versions of the C library, and not libgcc or libstdc++. The first patch in this series allows multilib configurations to enable -Os or -Oz while building libgcc by pulling any -Os or -Oz setting out of the CC and CFLAGS variables and appending them to the end of the compiler flags used for libgcc and other targets, overriding numerous uses of -O2 throughout the build system. The second patch fixes a bug in the ARM multilib configuration settings; the default values marm and mfloat-abi=soft were not specified; when -Os was the only option provided to the driver, the missing default values would cause the multilib selection code to fail to match the Os version. The third patch enables a new configuration option, --enable-multilib-space, which adds -Os as one of the multilib options and then extends any existing MULTILIB_EXCEPTIONS, MULTILIB_REQUIRED, MULTILIB_REUSE and MULTILIB_OSDIRNAMES settings, adding Os variants of each entry. This has been tested by building all 28 Zephyr toolchains and running a set of Zephyr tests using the resulting compilers. As an alternative, we could alter the multilib settings for each target, but that would touch many more files. If this is the preferred approach, we'll still need the first two patches in this series.
