GCCSDK for RISC OS version 4.7.4 release 3 released

The RISC OS GCCSDK developers are pleased to announce the GNU Compiler
Collection version 4.7.4 RISC OS release 3, which is now available for
download.

The main feature of this GCC release is support for the Raspberry Pi 3.
The compilers will now run on the Raspberry Pi 3 and produce executables
that run on the Raspberry Pi 3.

Other changes include

UnixLib: Fix for memory corruption when mixing VFP and non-VFP shared libraries at runtime (r6962).
UnixLib: Use LDREX/STREX instructions instead of SWP where depending on OS (r7043, 7075)
UnixLib: Set the character flag for /dev/dsp so that libraries like libSDL2 can detect it correctly. (r7099)

This release was taken from the ci.riscos.info build:
http://ci.riscos.info/job/gcc-4.7-native/128/

The release can be downloaded from the riscos.info repositories using PackMan,
which will fetch and install all the pieces for you, or you can follow the
manual installation instructions. For more details see:

www.riscos.info/index.php/GCC

Our thanks go to all those who have contributed to this release.

Thanks for the update.

Is there any plan for making UnixLib support runtime CPU feature checks for VFP/NEON etc?

It would allow us to speed up https in NetSurf.

Additionally we could potentially make use of faster NEON-based JPEG and PNG decoding in libpng and libjpeg-turbo.

That’s a bit of a fiddly one. There’s a lot of code in UnixLib which needs to change depending on what type of floating point is in use – there’s the pthread context switching, C library fenv functions, jmpbuf format, etc.

If you could build a version of NetSurf which used VFP hardfloat then runtime detection of additional VFP/NEON features would be fine. But using VFP/NEON in other builds is a lot trickier (you’d have to create and manage your own VFP contexts, and workaround linker issues where it complains about mismatched ABIs)

I can’t remember off the top of my head what other ABIs the softfloat ABI are compatible with. If it was safe for a hardfloat VFP binary/UnixLib to link to a softfloat shared object then you could potentially have two ‘stub’ netsurf binaries (one VFP, the other softfloat) which then links to the main NetSurf library (softfloat). Because the stub binary will be linked to a suitable version of UnixLib, it should be safe for the main binary to detect and use VFP/NEON features.

Of course the far simpler way of doing things would be to provide two different builds of NetSurf (or have two complete binaries within the app) – one for ARMv6 VFPv2 (or ARMv7 NEON) and the other for older architectures. With a program the size of NetSurf, I’m sure there must be plenty of bits of code which would benefit from targeting ARMv7 + VFP/NEON instead of ARMv3 + softfloat.

Is it possible to create a build of gcc/g++ using -mlibscl?
I have been looking for a build setting in GCCSDK but could not find it. Maybe I didn’t look hard enough though.

Do you mean linking the compiler with the SCL? I don’t think that’s possible – it’s a large Unix program itself, so likely to need Unixlib.

Or you mean building C source code with ‘gcc -mlibscl’? Does that not work for you?