Since GCC itself is written in C++, shouldn't C++ support be considered mandatory? I'm curious why the cxx use flag is toggleable in the gcc package in this case. Relatedly, should libstdc++ be part of the @system set?
Also to note that gcc itself is a system package
libstdc++ (virtual/libstdc++, sys-libs/libstdc++-v3 and sys-libs/libstdc++-v3-bin) in gentoo is a libstdc++v3 from gcc-3.3. It should not be in @system set as it's used only by old binary-only packages. I suggest ignoring this question in this bug. C++ is optional for bare-metal and cross-compiler targets without need for c++ support like 'crossdev -t avr' (optional C++) or 'crossdev -t mmix' (not implemented C++). Today C++ is not optional for non-cross-compilers: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass#n2334 is_cxx() { gcc-lang-supported 'c++' || return 1 ! is_crosscompile && tc_version_is_at_least 4.8 && return 0 use_if_iuse cxx } Note: it always returns success for non-crosscompilers. Did you break your system as a result of USE=-cxx? Why it's a problem in practice?
My logic is that if gcc (or for that matter any other package) is a system package that is written in C++, then C++ support in gcc is required to build it shouldn't be conditioned on a USE flag. If this USE flag is disabled in gcc then you'd be unable to compile C++ source code, including for gcc itself, which, as a system package, would seem to be an erroneous state of affairs. The question of libstdc++ is for the same reason. That said I just ran a test in a fresh stage3 chroot and apparently even with USE=-cxx, it still uses C++ internally to compile itself during its own merge, so apparently, surprisingly, USE=cxx is not required to build gcc itself. What about other packages with C++ source?
