configure checks for -maltivec OK But none/tests/ppc64/Makefile.am (and ppc32, too) passes the flag unconditionally. Reported by Bob Cochran.
Created attachment 88523 [details] patch to fix the build The attached patch should fix the build issue. There may be issues running the tests, though. Unfortunately I don't have a setup handy to test this.
Created attachment 88586 [details] patch v2 The prvious patch failed to remove -maltivec so did not work properly. Correct in this patch. Woule be good to confirm that there are not regressions when running the none/tests/ppc{64,32} buckets.
I'll re-try with patch v2; I saw that -maltivec and -DHAS_ALTIVEC got passed and was wondering if I am making a mistake somewhere.
Created attachment 88590 [details] Build and test log without applying patch v2.
Created attachment 88591 [details] Build and test log with patch v2 applied.
Valgrind: 14479, VEX: 2947 Test machine details: root@p5020ds:/home/anmol# cat /proc/cpuinfo processor : 0 cpu : e5500 clock : 1999.999995MHz revision : 1.2 (pvr 8024 0012) processor : 1 cpu : e5500 clock : 1999.999995MHz revision : 1.2 (pvr 8024 0012) timebase : 25000000 platform : CoreNet Generic model : fsl,P5020DS root@p5020ds:/home/anmol# uname -a Linux p5020ds 3.12.19-rt30-QorIQ-SDK-T1040-BSP-V1.1+g3d55c3c #1 SMP Fri Sep 5 11:20:24 CDT 2014 ppc64 GNU/Linux root@p5020ds:/home/anmol#
(In reply to Anmol P. Paralkar from comment #4) > Created attachment 88590 [details] > Build and test log without applying patch v2. The build(In reply to Anmol P. Paralkar from comment #4) > Created attachment 88590 [details] > Build and test log without applying patch v2. You must have mixed something up. The attachment contains this line: gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -I../../../include -I../../../coregrind -I../../../include -I../../../VEX/pub -I../../../VEX/pub -DVGA_ppc64be=1 -DVGO_linux=1 -DVGP_ppc64be_linux=1 -DVGPV_ppc64be_linux_vanilla=1 -DVGA_SEC_ppc32=1 -DVGP_SEC_ppc64be_linux=1 -Winline -Wall -Wshadow -g -m32 -Winline -Wall -O -g -mregnames -maltivec -m32 -DHAS_ALTIVEC -Wno-long-long -fno-stack-protector -Wno-write-strings -MT jm_insns-jm-insns.o -MD -MP -MF .deps/jm_insns-jm-insns.Tpo -c -o jm_insns-jm-insns.o `test -f 'jm-insns.c' || echo './'`jm-insns.c mv -f .deps/jm_insns-jm-insns.Tpo .deps/jm_insns-jm-insns.Po which did not produce an error, even though there is -maltivec on the command line of which you earlier claimed that the compiler does not support it. So you're probab;y not using the cross compiler but some native compiler.
Created attachment 88592 [details] perl tests/vg_regtest none/tests/ppc32 (without applying patch v2)
Created attachment 88593 [details] perl tests/vg_regtest none/tests/ppc64 (without applying patch v2)
Created attachment 88594 [details] perl tests/vg_regtest none/tests/ppc32 (after applying patch v2)
Created attachment 88595 [details] perl tests/vg_regtest none/tests/ppc64 (after applying patch v2)
> So you're probab;y not using the cross compiler but some native compiler. Confirming. All the testing I have posted logs for is native.
Florian, Yes, the build is a native build. These are the steps I followed on the linux board: make clean ./autogen.sh ./configure --prefix=$PWD 2>&1 | tee configure.log make 2>&1 | tee make.log make install 2>&1 | tee make.install.log make regtest 2>&1 | tee regtest-p5020ds-64b.default-build.`date | sed 's/ /-/g'`.log Regards, Anmol.
Florian, (and adding Carl and Maynard for their inputs on the later parts), Re: patch v2 -mabi=altivec would need to be abstracted out and made conditional under HAS_ALTIVEC and should appear alongside $(BUILD_FLAG_ALTIVEC) everywhere (or perhaps there could be one BUILD_FLAGS_ALTIVEC = -maltivec -mabi=altivec). Also, I get the feeling that -DALTIVEC was actually intended to be -DHAS_ALTIVEC and hence should be replaced by $(ALTIVEC_FLAG)? -- My understanding is that GCC (both: cross, native) for the Power Architecture will always accept -maltivec thereby causing the emission of AltiVec instructions and built-in's. So, while I agree with the scheme of your patch for preventing -maltivec & co. from being passed to a toochain in which they are not supported (as they are conditional upon HAS_ALTIVEC which, per configure.ac means that the toolchain accepts -maltivec) - however, we would not want to use -maltivec & co. when the underlying architecture does not have AltiVec. That information would come from auxv though, which I do not see being used in configure.ac (would it be OK to use auxv in configure.ac?); but I feel that the definition of HAS_ALTIVEC must then be that the toolchain accepts the AltiVec options and that the underlying architecture has AltiVec capability. There are instances such as this: none/tests/ppc64/jm-insns.c:242 #include "config.h" // HAS_ALTIVEC #if defined (HAS_ALTIVEC) # include <altivec.h> #endif none/tests/ppc64/jm-insns.c:7268 for (i=0; i<nb_vfargs; i++) { vec_in = (vector unsigned int)vfargs[i]; which need to be modified to provide an altivec free build and test experience when there is no altivec. If this makes sense, once Florian checks in his work, I'll work on getting the testsuite going on the e5500 to test this out. Thank you very much. Regards, Anmol.
(In reply to Anmol P. Paralkar from comment #14) > Florian, (and adding Carl and Maynard for their inputs on the later parts), > > Re: patch v2 > > -mabi=altivec would need to be abstracted out and made conditional under > HAS_ALTIVEC > and should appear alongside $(BUILD_FLAG_ALTIVEC) everywhere (or perhaps > there could > be one BUILD_FLAGS_ALTIVEC = -maltivec -mabi=altivec). I've done this in r14566. > > Also, I get the feeling that -DALTIVEC was actually intended to be > -DHAS_ALTIVEC and hence should be replaced by $(ALTIVEC_FLAG)? I thin that the VSX testcase in none/tests/ppc32 reiles on ALTIVEC being defined. So I think this is OK as is. > My understanding is that GCC (both: cross, native) for the Power > Architecture will > always accept -maltivec thereby causing the emission of AltiVec instructions > and built-in's. Yes that is true. We need to change the Makefile.am such that the test is only included, if the host supports altivec instructions. That is the easy part. The (perhaps) not so easy part is to figure out whether the host supports altivec insns or not. I do not know offhand what is a robust way to do that. Perhaps cat /proc/cpuinfo | grep 'altivec supported' is good enough ... I do not know. So,yes, something needs to be added to configure.ac to do it. I'm marking this bug as fixed as it was only converned with build issues which I believe are resolved now. If not feel free to reopen.
On Wed, 2014-09-24 at 22:12 +0000, Florian Krohm wrote: > https://bugs.kde.org/show_bug.cgi?id=338731 > > Florian Krohm <florian@eich-krohm.de> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |FIXED > Status|UNCONFIRMED |RESOLVED > > --- Comment #15 from Florian Krohm <florian@eich-krohm.de> --- > (In reply to Anmol P. Paralkar from comment #14) > > Florian, (and adding Carl and Maynard for their inputs on the later parts), > > > > Re: patch v2 > > > > -mabi=altivec would need to be abstracted out and made conditional under > > HAS_ALTIVEC > > and should appear alongside $(BUILD_FLAG_ALTIVEC) everywhere (or perhaps > > there could > > be one BUILD_FLAGS_ALTIVEC = -maltivec -mabi=altivec). > > I've done this in r14566. > > > > > Also, I get the feeling that -DALTIVEC was actually intended to be > > -DHAS_ALTIVEC and hence should be replaced by $(ALTIVEC_FLAG)? > > I thin that the VSX testcase in none/tests/ppc32 reiles on ALTIVEC being > defined. So I think this is OK as is. > > > My understanding is that GCC (both: cross, native) for the Power > > Architecture will > > always accept -maltivec thereby causing the emission of AltiVec instructions > > and built-in's. > > Yes that is true. We need to change the Makefile.am such that the test is only > included, if the host supports altivec instructions. That is the easy part. The > (perhaps) not so easy part is to figure out whether the host supports altivec > insns or not. I do not know offhand what is a robust way to do that. > Perhaps cat /proc/cpuinfo | grep 'altivec supported' is good enough ... I do > not know. > So,yes, something needs to be added to configure.ac to do it. > > I'm marking this bug as fixed as it was only converned with build issues which > I believe are resolved now. If not feel free to reopen. > We do have a flag HAS_ALTIVEC which is used to include Altivec tests. See the test case none/tests/ppc64/jm-insns.c for an example. I think the needed support in the make file is there you just need to put your Altivec test inside a #if (HAS_ALTIVEC) #endif block and you should be good to go. Carl Love