Hi Richard, I've tested your patch for both altivec and spe and it works fine.
Regards, Alex > -----Original Message----- > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] > Sent: Wednesday, January 29, 2014 1:39 PM > To: Phil Blundell > Cc: Sardan Alexandru Cezar-B41700; Udma Catalin-Dan-B32721; openembedded- > c...@lists.openembedded.org > Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc > linux verses linux-gnuspe" > > On Fri, 2014-01-24 at 20:56 +0000, Phil Blundell wrote: > > On Thu, 2014-01-23 at 18:22 +0000, alexandru.sar...@freescale.com > wrote: > > > [Alex Sardan] No. The more generic target powerpc-none-linux will not > > > generate SPE code and the powerpc-none-linux-gnuspe target that > generates > > > SPE will not be able to generate Altivec. > > > > Why not? As far as I can tell from the gcc configury, the target > string > > only affects the defaults (i.e. powerpc-*-linux gets -mno-spe > > -mno-altivec, powerpc-*-linuxaltivec gets -maltivec -mno-spec, and > > powerpc-*-linuxspe gets -mno-altivec -mspe). There doesn't seem to be > > any real impact beyond this that would make the compiler binary > > fundamentally incapable of generating either type of instruction if you > > pass the appropriate options on the command line. > > I had a closer look at this. The config.gcc case statements for powerpc > only appear to let you include rs6000/linuxaltivec.h or > rs6000/linuxspe.h, there doesn't appear to be a target you can pass in > to get both. > > Looking at the code in those files, I don't see any reason why you can't > actually include support for both however. As such, I just hacked a > build with: > > tm_file="${tm_file} rs6000/linuxaltivec.h" > tm_file="${tm_file} rs6000/linuxspe.h rs6000/e500.h" > > and it certainly seems to build ok and compile things (this was just for > qemuppc). I didn't try building altivec or spe specific things but > looking at the code, I can't see any reason it wouldn't work at least in > theory. > > I'd suggest the easiest way to resolve this may be to patch gcc to > include support for all the modes. > > Cheers, > > Richard > > _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
