[gccsdk] New VFP/NEON capable GCC release?

Chris Gransden 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[1] 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
> options:

> -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
added.

-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.

Chris.





More information about the gcc mailing list