Error building GCC 6.1.0 libstdc++
Hi, I'm running into a build problem when building GCC 6.1.0: /home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./gcc/xgcc -shared-libgcc -B/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./gcc -nostdinc++ -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/src -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/src/.libs -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/libsupc++/.libs -B/home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/bin/ -B/home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/lib/ -isystem /home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/include -isystem /home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/sys-include -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./ld-x c++-header -nostdinc++ -g -O2 -I/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include/powerpc-eabispe -I/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include -I/home/patrick/src/e7/toolchain/src/gcc-combined/libstdc++-v3/libsupc++ -O2 -g /home/patrick/src/e7/toolchain/src/gcc-combined/libstdc++-v3/include/precompiled/extc++.h -o powerpc-eabispe/bits/extc++.h.gch/O2g.gch In file included from /home/patrick/src/e7/toolchain/src/gcc-combined/libstdc++-v3/include/precompiled/extc++.h:69:0: /home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include/ext/throw_allocator.h:545:18: error: 'uniform_real_distribution' in namespace 'std' does not name a template type typedef std::uniform_real_distribution distribution_type; ^ /home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include/ext/throw_allocator.h:546:18: error: 'mt19937' in namespace 'std' does not name a type typedef std::mt19937 engine_type; ^~~ I've done some analysis of this and it turns out to be an issue with the C library I'm using. The configure test "checking for ISO C99 support to TR1 in " is failing. This stops _GLIBCXX_USE_C99_STDINT_TR1 from being defined which subsequently causes the above build failure because doesn't include anymore. Is this a bug in the build system? If _GLIBCXX_USE_C99_STDINT_TR1 is required then should the configure abort? Alternatively, should libstdc++ still build without _GLIBCXX_USE_C99_STDINT_TR1? Patrick
PowerPC rs6000 multilib combinations
Hi, I've recently been using a target (e200z6) where a "-mno-spe -mabi=no-spe" libgcc was required. The closest combination provided by 4.9.1 was "-mno-spe -mabi=no-spe -mno-isel". My builds disable spe, but leave isel enabled. Unfortunately, with this combination of options gcc uses an incompatible libgcc which includes spe instructions. I have attached a patch which enables the "-mno-spe -mabi=no-spe" multilib. It seems a bit broken that gcc would use an spe version of libgcc when I specify "no-spe". Hopefully someone finds the patch useful. Kind regards, Patrick --- gcc/config/rs6000/t-spe.orig 2014-09-16 13:55:57.649114878 +1000 +++ gcc/config/rs6000/t-spe 2014-09-16 13:56:37.393116284 +1000 @@ -23,6 +23,7 @@ # -mcpu=7400 -maltivec -mabi=altivec # -mcpu=7400 -msoft-float # -msoft-float +# -mno-spe -mabi=no-spe # -mno-spe -mabi=no-spe -mno-isel # so we'll need to create exceptions later below. @@ -56,7 +57,6 @@ *msoft-float/*mno-spe* \ *msoft-float/*mabi=no-spe* \ *msoft-float/*mno-isel* \ - mno-spe/mabi=no-spe \ mno-spe/mno-isel \ mabi=no-spe/mno-isel \ mno-isel/mlittle \ @@ -67,7 +67,6 @@ mcpu=7400/maltivec/mlittle \ mabi=no-spe/mlittle \ mno-spe/mno-isel/mlittle \ - mno-spe/mabi=no-spe/mlittle \ mabi=altivec/mlittle \ maltivec/mlittle \ maltivec/mabi=altivec/mlittle
Re: Obsolete powerpc*-*-*spe*
On 15/02/17 01:49, Segher Boessenkool wrote: It is also used in many PPC based microcontrollers, which are used in the automotive industry and other places where you need highly reliable and robust but powerful microcontrollers. However, gcc support for these has traditionally been poor - there is little support for the variety of cores and configurations available from Freescale/NXP. I believe there is a chicken-and-egg situation here - few people use gcc with these devices because there is poorer device support compared to Freescale CodeWarrior or Green Hills, and there is little incentive for gcc developers (such as the CodeSourcery or IBM PPC folks) to support devices in gcc if no one uses that combination. Yes, we use GCC also one these chips, however, due to the lack of VLE support the situation is even worse. Looks like support for the non-IBM PowerPC is dead in GCC. I can understand this pretty well. It's not true though; we still support all those cores, just not the VLE extension (we never have), and I propose GCC 7 will drop the SPE extension as well -- not all other support we have for those cores. They will have to use soft float, alas. Will the SPFP APU still be supported? Kind regards, Patrick
Re: Obsolete powerpc*-*-*spe*
On 15/02/17 01:49, Segher Boessenkool wrote: With the Qualcomm takeover of Freescale/NXP I guess the PowerPC has no future in this area and they will move to ARM for the processor cores. That is my understanding as well, yes. Our reps have suggested that the opposite may well be the case: It's Qualcomm buying into a large segment of the automotive MCU market. I know of at least two issues they will face with an ARM takeover: 1. There's an enormous amount of legacy PowerPC code out there. 2. Currently only small (Cortex-M0/M3) cores are available in the 150C+ operating temperature ratings required for some automotive (engine bay or on engine) installations. Of course these things can be overcome, but it will take time and effort. Patrick
