Re: [gccsdk] New VFP/NEON capable GCC release?

In article <55C26895.9030601@sky.com>,
Lee Noar <leenoar@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.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK