When configuring gcc for use on PowerPC e200/e500 platform, it will default to always generating a single precision floating point code, unless appropriate compile time flag is specified (-mfloat-gprs=double). This is very inconvenient, considering the fact that most chips in question support double precision floating point (e500v2 and e200z6, comprising the majority of newer chips). GCC has a configuration flag, --enable-e500-double which makes it to use double precision floating point by default on this platform. It makes sense, therefore, to add an appropriate local USE flag to toolchain eclass, akin to "altivec" or mips-specific "fixed-point". Reproducible: Always Steps to Reproduce:
i dont want to go adding random USE flags for minor targets. you can simply add EXTRA_ECONF="--enable-e500-double" to your build env for gcc.
Strictly speaking, this is not a minor target, but a rather major one. To obtain reasonable performance on e200/e500 everything must be recompiled, as floating point ABI is completely different and incompatible with normal PowerPC. These are popular processors in the embedded world and hopefully gentoo will come to support them fully one day (when eglibc hits the portage).
everybody's target is major to them. every package in the tree should cleanly support CFLAGS, or it's a bug and you should be filing one as such. what CTARGET exactly are you using ?
(In reply to comment #3) > everybody's target is major to them. every package in the tree should cleanly > support CFLAGS, or it's a bug and you should be filing one as such. This is a slightly different issue then CFLAGS, after all. The closer analogy would be a n32/n64 use flag of MIPS. > > what CTARGET exactly are you using ? > My CHOST is set to powerpc-linux-gnuspe, so CTARGET stays to be powerpc.
i dont think it is analogous to n64/n32 at all. those ABIs change all register sizes (and iirc, the caller/callee sets), as well as the kernel ABI. plus, that doesnt really help your argument considering i'm not a fan of those existing in the first place. what CFLAGS exactly do you use normally ? i dont have a problem having the code pass --enable-e500-double if it detects the user has CFLAGS targeting a new enough ppc, or has "-mfloat-gprs=double". or go the route we already have today with softfloat. use a CTARGET of: powerpc-gprsdouble-linux-gnu
> > what CFLAGS exactly do you use normally ? Errh, why are we discussing CFLAGS in the first place? My original bug report is about a "configure" switch to pass during the actual sys-devel/gcc compilation, it has nothing to do with other stuff. To answer your question, I used to have "-mspe -mfloat-gprs=double" in my CFLAGS, but after recompiling the gcc with "--enable-e500-double" I only have the distro default CFLAGS set. This is quite an improvement, considering that there are quite a few of those unfortunate packages which do not pass CFLAGS consistently to all targets, resulting in evil bugs and crashes, when some targets suddenly compile to a different version of floating point abi. I actually filed a bug report to gcc to make "--enable-e500-double" the default on *-gnuspe gcc build, but they decided not to. This is very unfortunate, considering that e500 chips are powerful enough these days to support fast native compilations, while most low-end e200 stuff (where double precision is not available) is done through cross-compiling and other hoop jumping.
Created attachment 263657 [details, diff] toolchain.eclass.patch if you didnt snip my entire comment, you might have included the part where i told you why i was looking at the CFLAGS value
(In reply to comment #7) > Created an attachment (id=263657) [details] > toolchain.eclass.patch > > if you didnt snip my entire comment, you might have included the part where i > told you why i was looking at the CFLAGS value > I don't think the proposed snippet is a good approach. The configure flag is necessary to abolish the need for the compile time flag. After one compiles gcc with --enable-e500-double, he will naturally remove the -mfloat-gprs=double from his CFLAGS (this may happen inadvertently, as part of new system image deployment). Which, in turn, will lead to the next compile of gcc getting out incorrect. Different CTARGET seems more reasonable to me, if this is the accepted way gentoo handles sub-architectures. It appears, there are some people who use powerpc-e500v2-linux-gnuspe target multiplet for this architecture, but it is not recognized as is by the gcc configure (apart from the *spe* part), so explicit flag is still necessary.
i'm not adding a USE flag. i dont want more minor explosion especially because it causes such a headache when it comes to masking and crossdev. keying off of CTARGET is fine along the lines of: + is-flagq -mfloat-gprs=double && confgcc+=" --enable-e500-double" + [[ ${CTARGET//_/-} == *-e500v2-* ]] && confgcc+=" --enable-e500-double"
(In reply to comment #9) > i'm not adding a USE flag. i dont want more minor explosion especially because > it causes such a headache when it comes to masking and crossdev. > > keying off of CTARGET is fine along the lines of: > > + is-flagq -mfloat-gprs=double && confgcc+=" --enable-e500-double" > + [[ ${CTARGET//_/-} == *-e500v2-* ]] && confgcc+=" --enable-e500-double" > I'm fine with the CTARGET.
please make sure i havent screwed things up in the process ... and if you know of other CTARGET's that people are using, let us know so i can tweak the match http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.450&r2=1.451
