Can we drop the softfloat patch present on the gcc ebuilds? [[ ${CTARGET} == *-softfloat-* ]] && epatch "${FILESDIR}"/4.4.0/gcc-4.4.0-softfloat.patch The patch is from bug 75585, and its not applied upstream. Besides we now force --with-float=soft on the toolchain.eclass. Its giving issues on xulrunner-2.0 and other apps while on other distros it doesn't happen...
i'm not hardcoding yet more targets here. the patch not being upstream really isnt an argument against it historically considering upstream considered the crappy behavior "usable" (it wasnt). if gcc-4.5+ operates correctly when using the --with-float=soft configure flag, i dont mind dropping it there.
And why not with 4.4? I've just tried removing the patch and building xulrunner-2.0 and it works fine. With the patch i just get: armv5tel-softfloat-linux-gnueabi-gcc -o armopts-gnu.o -march=armv7-a -mfpu=neon -c armopts-gnu.S armv5tel-softfloat-linux-gnueabi-gcc -o armfrag-gnu.o -march=armv7-a -mfpu=neon -c armfrag-gnu.s armfrag-gnu.s: Assembler messages: armfrag-gnu.s:473: Error: selected processor does not support ARM mode `vld1.64 {D0},[r4,:64],r2' armfrag-gnu.s:475: Error: selected processor does not support ARM mode `vld1.64 {D1},[r4,:64],r2' armfrag-gnu.s:477: Error: selected processor does not support ARM mode `vld1.64 {D2},[r4,:64],r2' armfrag-gnu.s:479: Error: selected processor does not support ARM mode `vld1.64 {D3},[r4,:64],r2' armfrag-gnu.s:481: Error: selected processor does not support ARM mode `vld1.64 {D4},[r4,:64],r2' armfrag-gnu.s:483: Error: selected processor does not support ARM mode `vld1.64 {D5},[r4,:64],r2' armfrag-gnu.s:485: Error: selected processor does not support ARM mode `vld1.64 {D6},[r4,:64],r2' armfrag-gnu.s:487: Error: selected processor does not support ARM mode `vld1.64 {D7},[r4,:64]' armfrag-gnu.s:489: Error: selected processor does not support ARM mode `vst1.64 {D0},[r5,:64],r2' armfrag-gnu.s:491: Error: selected processor does not support ARM mode `vst1.64 {D1},[r5,:64],r2' armfrag-gnu.s:493: Error: selected processor does not support ARM mode `vst1.64 {D2},[r5,:64],r2' armfrag-gnu.s:495: Error: selected processor does not support ARM mode `vst1.64 {D3},[r5,:64],r2' armfrag-gnu.s:497: Error: selected processor does not support ARM mode `vst1.64 {D4},[r5,:64],r2' armfrag-gnu.s:499: Error: selected processor does not support ARM mode `vst1.64 {D5},[r5,:64],r2' armfrag-gnu.s:501: Error: selected processor does not support ARM mode `vst1.64 {D6},[r5,:64],r2' armfrag-gnu.s:503: Error: selected processor does not support ARM mode `vst1.64 {D7},[r5,:64]' armfrag-gnu.s:514: Error: selected processor does not support ARM mode `vdup.s16 Q0,r3' armfrag-gnu.s:515: Error: selected processor does not support ARM mode `vldmia r2,{D16-D31}' armfrag-gnu.s:516: Error: selected processor does not support ARM mode `vqadd.s16 Q8,Q8,Q0' armfrag-gnu.s:517: Error: selected processor does not support ARM mode `vqadd.s16 Q9,Q9,Q0' armfrag-gnu.s:518: Error: selected processor does not support ARM mode `vqadd.s16 Q10,Q10,Q0' armfrag-gnu.s:519: Error: selected processor does not support ARM mode `vqadd.s16 Q11,Q11,Q0' armfrag-gnu.s:520: Error: selected processor does not support ARM mode `vqadd.s16 Q12,Q12,Q0' armfrag-gnu.s:521: Error: selected processor does not support ARM mode `vqadd.s16 Q13,Q13,Q0' armfrag-gnu.s:522: Error: selected processor does not support ARM mode `vqadd.s16 Q14,Q14,Q0' armfrag-gnu.s:523: Error: selected processor does not support ARM mode `vqadd.s16 Q15,Q15,Q0' armfrag-gnu.s:524: Error: selected processor does not support ARM mode `vqmovun.s16 D16,Q8' armfrag-gnu.s:525: Error: selected processor does not support ARM mode `vqmovun.s16 D17,Q9' armfrag-gnu.s:526: Error: selected processor does not support ARM mode `vqmovun.s16 D18,Q10' armfrag-gnu.s:527: Error: selected processor does not support ARM mode `vst1.64 {D16},[r0,:64],r1' armfrag-gnu.s:528: Error: selected processor does not support ARM mode `vqmovun.s16 D19,Q11' Its normal that it builds with those flags, since it detects those flags at runtime. If we don't remove the patch, then i have to patch xulrunner...i don't see whats the point on patching software because we're using a patch nobody else does :/
As you can see below, in the case of -softfloat- toolchain, the command line passed to the assembler is: /usr/libexec/gcc/armv5tel-softfloat-linux-gnueabi/as -march=armv5te -mfpu=softvfp -meabi=5 -o test.o test.s And for -none- toolchain it is: /usr/libexec/gcc/armv5tel-none-linux-gnueabi/as -march=armv5te -mfpu=neon -meabi=5 -o test.o test.s The problem is that due to the patch in question, the -softfloat- gcc takes the liberty of converting the original "-mfpu=neon" option to "-mfpu=softvfp". And this breaks some of the packages which are using ARM NEON optimizations including xulrunner (a part of mozilla firefox). $ cat test.s .text vmov d0, d1 # crossdev -t armv5tel-softfloat-linux-gnueabi # crossdev -t armv5tel-none-linux-gnueabi $ armv5tel-softfloat-linux-gnueabi-gcc -v -mfpu=neon -c test.s Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/armv5tel-softfloat-linux-gnueabi/gcc-bin/4.5.2/armv5tel-softfloat-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv5tel-softfloat-linux-gnueabi/4.5.2/lto-wrapper Target: armv5tel-softfloat-linux-gnueabi Configured with: /var/tmp/portage/cross-armv5tel-softfloat-linux-gnueabi/gcc-4.5.2/work/gcc-4.5.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/armv5tel-softfloat-linux-gnueabi/gcc-bin/4.5.2 --includedir=/usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.5.2/include --datadir=/usr/share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.5.2 --mandir=/usr/share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.5.2/man --infodir=/usr/share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.5.2/info --with-gxx-include-dir=/usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.5.2/include/g++-v4 --host=x86_64-pc-linux-gnu --target=armv5tel-softfloat-linux-gnueabi --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --with-float=soft --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.5.2/python --enable-checking=release --disable-libgcj --with-arch=armv5te --enable-languages=c,c++ --with-sysroot=/usr/armv5tel-softfloat-linux-gnueabi --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.2 p1.1, pie-0.4.5' Thread model: posix gcc version 4.5.2 (Gentoo 4.5.2 p1.1, pie-0.4.5) COLLECT_GCC_OPTIONS='-v' '-mfpu=neon' '-c' '-march=armv5te' '-mfloat-abi=soft' /usr/libexec/gcc/armv5tel-softfloat-linux-gnueabi/as -march=armv5te -mfpu=softvfp -meabi=5 -o test.o test.s test.s: Assembler messages: test.s:3: Error: selected processor does not support ARM mode `vmov d0,d1' $ armv5tel-none-linux-gnueabi-gcc -v -mfpu=neon -c test.s Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/armv5tel-none-linux-gnueabi/gcc-bin/4.5.2/armv5tel-none-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv5tel-none-linux-gnueabi/4.5.2/lto-wrapper Target: armv5tel-none-linux-gnueabi Configured with: /var/tmp/portage/cross-armv5tel-none-linux-gnueabi/gcc-4.5.2/work/gcc-4.5.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/armv5tel-none-linux-gnueabi/gcc-bin/4.5.2 --includedir=/usr/lib/gcc/armv5tel-none-linux-gnueabi/4.5.2/include --datadir=/usr/share/gcc-data/armv5tel-none-linux-gnueabi/4.5.2 --mandir=/usr/share/gcc-data/armv5tel-none-linux-gnueabi/4.5.2/man --infodir=/usr/share/gcc-data/armv5tel-none-linux-gnueabi/4.5.2/info --with-gxx-include-dir=/usr/lib/gcc/armv5tel-none-linux-gnueabi/4.5.2/include/g++-v4 --host=x86_64-pc-linux-gnu --target=armv5tel-none-linux-gnueabi --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/armv5tel-none-linux-gnueabi/4.5.2/python --enable-checking=release --disable-libgcj --with-arch=armv5te --enable-languages=c,c++ --with-sysroot=/usr/armv5tel-none-linux-gnueabi --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.2 p1.1, pie-0.4.5' Thread model: posix gcc version 4.5.2 (Gentoo 4.5.2 p1.1, pie-0.4.5) COLLECT_GCC_OPTIONS='-v' '-mfpu=neon' '-c' '-march=armv5te' /usr/libexec/gcc/armv5tel-none-linux-gnueabi/as -march=armv5te -mfpu=neon -meabi=5 -o test.o test.s COMPILER_PATH=/usr/libexec/gcc/armv5tel-none-linux-gnueabi/4.5.2/:/usr/libexec/gcc/armv5tel-none-linux-gnueabi/4.5.2/:/usr/libexec/gcc/armv5tel-none-linux-gnueabi/:/usr/lib/gcc/armv5tel-none-linux-gnueabi/4.5.2/:/usr/lib/gcc/armv5tel-none-linux-gnueabi/ LIBRARY_PATH=/usr/lib/gcc/armv5tel-none-linux-gnueabi/4.5.2/:/usr/lib/gcc/armv5tel-none-linux-gnueabi/4.5.2/../../../../armv5tel-none-linux-gnueabi/lib/:/usr/armv5tel-none-linux-gnueabi/lib/:/usr/armv5tel-none-linux-gnueabi/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-mfpu=neon' '-c' '-march=armv5te'
My understanding is that the softfloat patch, originating from 2004-2005, is only needed (or used to be needed?) for uclibc toolchains. But for -gnueabi toochains (those which are using EABI), the floating point ABI is clearly documented and defined to be "soft", "softfp" or "hard". And it's probably better not to mess up with it, but trust the toolchain to do the right job even without patches. And if it does not do it right, then report bugs upstream.
(In reply to comment #1) > i'm not hardcoding yet more targets here. the patch not being upstream really > isnt an argument against it historically considering upstream considered the > crappy behavior "usable" (it wasnt). Could you elaborate on this "crappy behavior" and give some examples? What would break if this patch is dropped?
softfloat has nothing to do with uclibc or any C library read bug 75585 for the history of the patch
(In reply to comment #6) > softfloat has nothing to do with uclibc or any C library Softfloat is the implementation of floating point math via performing calls to a floating point emulation library (in the gcc case it is libgcc). And in the real world this surely has to be taken into account by uclibc or any C library if they use low level assembly optimizations or some other ABI-dependent code. Thanks for confirming that we should not be worried about uclibc. My primary concern was that dropping the patch may cause some regressions for uclibc. But if this is not the case, then everything is surely much more simple. Especially considering that uclibc gentoo stages are not maintained by anyone at the moment. > read bug 75585 for the history of the patch I understand that this patch was clearly useful years ago. But a lot of time has passed since then and now we are more interested in correct behaviour, and much less in the "history". So with all the respect to the people who invested their efforts into this softfloat patch, I'm getting more and more convinced that it's time to retire it. Nowadays anyone who wants softfloat is surely better to use ARM EABI (*-gnueabi or *-uclibceabi toolchains).
i know how float works for arm targets, so i dont know why you're posting that trivia. further, you yourself asked for the history and thus i pointed you to it. if you dont actually care about things, then dont ask.
(In reply to comment #8) > you yourself asked for the history and thus i pointed you to > it. if you dont actually care about things, then dont ask. I asked you about "what would break if this patch is dropped?" and I'm still waiting for a definite answer. Just to make it clear. We are talking about an old hack which was never approved by upstream gcc maintainers. You or somebody else has to clearly explain why it is necessary in gentoo toolchain *nowadays* in order to justify its existence. And the plain fact is that this patch causes some real problems today (see comment 2), otherwise nobody would file this bug in the first place. Risking to be blamed for posting trivia again, I still would like to point out that ARM EABI support has been introduced in gcc 4.1, which was released in 2006. You should understand yourself that any links to the information from 2004/2005 are a little bit outdated and are not so relevant now. EABI intruduces upstream maintained softfloat support. I'm expecting the toolchain herd to: 1. confirm the bug (see comment 2 and comment 3) 2. either explain why the problematic patch can't be dropped or alternatively propose a better solution Thanks.
(In reply to comment #1) > i'm not hardcoding yet more targets here. the patch not being upstream really > isnt an argument against it historically considering upstream considered the > crappy behavior "usable" (it wasnt). > > if gcc-4.5+ operates correctly when using the --with-float=soft configure flag, > i dont mind dropping it there. If we can't have it dropped on 4.4, then okay with 4.5+
they really arent outdated. try reading the whole bug for the reason for it in the first place. if dropping the patch results in horrible performance depredation, then sounds to me like keeping it makes more sense and just fixing the minor spec bugs.
(In reply to comment #11) > if dropping the patch results in horrible performance > depredation, then sounds to me like keeping it makes more sense and just fixing > the minor spec bugs. Could you please first provide exact step by step instructions, explaining how to reproduce this horrible performance degradation you are talking about? I don't even need any benchmark results as a proof, just providing an example of stray FPA or VFP instruction unexpectedly generated with a softfloat toolchain after dropping the patch would be enough.
if you arent going to bother reading the bug i continue to point you at, then dont bother asking for clarification
(In reply to comment #13) > if you arent going to bother reading the bug i continue to point you at, Are you a psychic? If not, then please stop assuming things you have no idea about. > then dont bother asking for clarification I would not bother if you did your job properly and provided an acceptable solution for this bug already. And you are definitely lacking at least the ability to report your problems properly, so your claim about the performance degradation can't be confirmed and I can't provide any help resolving it. Please take a look at the following article, it explains some basic things (and also see my comment 3 as an example): http://freshmeat.net/articles/how-to-report-bugs-effectively
Any news? :(
(In reply to comment #1) > if gcc-4.5+ operates correctly when using the --with-float=soft configure flag, > i dont mind dropping it there. I'm taking this as an approval to drop it for 4.5.3+.
The patch was dropped from 4.5.3+...all happy, thanks
Please adapt /usr/portage/arch/arm/package.use.mask # Until we get bug 372199 fixed or subprofiles, we have to mask this www-client/firefox alsa webm
