[gccsdk] New VFP/NEON capable GCC release?
chrisg at care4free.net
Wed Aug 5 14:40:25 PDT 2015
In article <55C26895.9030601 at sky.com>,
Lee Noar <leenoar at sky.com> wrote:
> On 05/08/15 18:58, Theo Markettos wrote:
> > It appears that there's some demand for a build of GCC that supports VFP
> > and NEON. Currently our existing release build 4.7.4-Rel1-1 doesn't support
> > it. Would it make sense to cut a new release build? This would also
> > involve releasing SharedUnixLibrary 0.13 which is a necessary prerequisite.
> > Are there any gotchas to be aware of, or loose ends that need tidying up
> > first?
> I would be in favour of a new release. As you say, VFP is generating
> some interest and there have also been fixes to module code generation,
> Unixlib and the dynamic linker. A new release would also include the
> changes required for a Qt5 web browser to be run.
> As far as VFP is concerned, I'm in the middle of developing a version of
> Qt for the RPi which uses VFP and OpenGL. I'm compiling it using the
> -mfloat-abi=softfp -mfpu=vfp -mtune=arm1176jzf-s -march=armv6zk
> So far I've got a very basic version of one of the opengl examples
> running that displays a spinning triangle.
> While it's difficult to say whether the code paths are touching many VFP
> instructions, looking at the binary shows that the triangle render
> function does contain VFP instructions so I think it's safe to say that
> VFP code is being exercised.
> Not exactly an exhaustive test, but there don't seem to be any issues.
> I can't really say anything about NEON.
> Obviously, it will be necessary to package the VFP versions of the
> runtime libraries. The shared libraries should be stored in
> !SharedLibs.lib.abi-2/0.vfp. Binaries needs to be linked with
> -mfpu=vfp so that the dynamic linker knows to look for VFP libraries.
> I can't remember if I documented that; I'll have to check.
Me too. I've been using similar compiler options. Been testing for about
4years. Seems much more stable now compared to when support was first
-mno-unaligned-access -mfloat-abi=softfp -mfpu=vfp -mcpu=arm1176jzf-s
Using these options the same executable then runs on RPi 1 & 2, Beagleboard
, Pandaboard and IGEPv5. Without the -mno-unaligned-access alignment
exceptions need turning off and occasionally even with this they need
turning off. e.g DosBox and mplayer.
Using -mfpu=neon produces a few internal compiler errors building certain
programs. I've not tested much with this option. Plus it won't then run on
the RPi 1.
More information about the gcc