C Compiler Warnings

Spoiler alert:

[…]All the flags presented so far can be combined into the following list, provided below for copy-pasting purposes :
-Wall -Wextra -Wcast-qual -Wcast-align -Wstrict-aliasing -Wpointer-arith -Winit-self -Wshadow -Wswitch-enum -Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls -Wfloat-equal -Wundef -Wvla -Wdeclaration-after-statement -Wc++-compat


GCC: Mitigation against unsafe data speculation (CVE-2017-5753)

The patches I posted earlier this year for mitigating against
CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
which it became obvious that a rethink was needed. This mail, and the
following patches attempt to address that feedback and present a new
approach to mitigating against this form of attack surface.[…]



GCC 8.1 Released

GCC 8.1 is a major release containing substantial new functionality not available in GCC 7.x or previous GCC releases.

This releases features significant improvements in the emitted diagnostics, including improved locations, location ranges and fix-it hints (especially in the C++ front-end), and various new warnings have been added.

Profile driven optimizations have been significantly improved, on x86 functions are now split into hot and cold regions by default. The link time optimizations now have a new way of emitting the DWARF debug information, which makes LTO optimized code more debuggable. New loop optimizers have added and existing improved and some, like -ftree-loop-distribution, -floop-unroll-and-jam and -floop-interchange have been enabled by default at-O3.

The AArch64 target now supports the Scalable Vector Extension, whichfeatures vectors with runtime determined number of elements.



GCC 7.3 released, with Spectre Variant2 for x86/ppc

Subject: GCC 7.3 Released
Date: Thu, 25 Jan 2018 10:41:30 +0100 (CET)
To: gcc-announce@gcc.gnu.org, gcc@gcc.gnu.org, info-gnu@gnu.org

The GNU Compiler Collection version 7.3 has been released.

GCC 7.3 is a bug-fix release from the GCC 7 branch containing important fixes for regressions and serious bugs in GCC 7.2 with more than 99 bugs fixed since the previous release.

This release includes code generation options to mitigate Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets.


PS: Microsoft updated MSC earlier. I’m not sure about status of Intel C Compiler or ARM C compiler. CLang has some changes in the pipeline:



Linaro Binary Toolchain Release GCC 6.3-2017.02

Linaro does regular drops of core tools, and these days they’re using GCC v6.x, and GCC has a few new language features and target architecture features recently. Excerpting the Linaro announcement:

The Linaro GCC 6.3-2017.02 Release is now available. […]  The Linaro binary toolchain is a collection of x86-hosted GNU cross-toolchains targeting a variety of ARM architecture targets. Linaro TCWG provides these toolchains as a service to our members. Due to hardware availability, system-image availability, validation complexity, and user-base size, not all host and target toolchain combinations can be validated by Linaro with the same rigor. The most rigorously validated targets are little-endian and hardfloat implementations of the 32-bit ARMv7 (arm), 32-bit ARMv8 (armv8), and 64-bit ARMv8 (aarch64) architectures.  Linaro recommends those targets to our members. […] The host system upon which the cross-compiler will run requires a minimum of glibc 2.14, because of API changes to glibc’s memcpy API. Linaro recommends using the 64-bit x86_64 host toolchains as the 32-bit i686 host toolchains and the 32-bit mingw host toolchains will only be provided as long as there is sufficient member interest to justify their continued availability. […] The GCC 6 Release series has significant changes from the GCC 5 release series.  For an explanation of the changes please see the following website[1]. For help in porting to GCC 6 please see the following explanation[2]. […]

[1] https://gcc.gnu.org/gcc-6/changes.html
[2] https://gcc.gnu.org/gcc-6/porting_to.html


See the full announcement for more details:

Android deprecates GCC, switch to Clang

From the Android NDK Changelog for NDK Build 2490520:

    PSA: Everyone should be switching to Clang.
    Clang has been updated to 3.8svn (r243773, build 2481030).
        Note that this is now a nearly pure upstream clang.
        Also note that Clang packaged in the Windows 64 NDK is actually 32-bit.
    Support for emulated TLS.
        __thread is now supported by the compiler by emulating ELF TLS with pthread thread-specific data.
        C++11 thread_local will work in some cases, but will not work for data with non-trivial destructors except when running on Marshmallow (android-23) or newer because those cases require support from libc.
        Does not yet work with Aarch64 when TLS variables are accessed from a shared library.

    GCC in the NDK is now deprecated.
        Time to start using Clang if you haven’t already. If you have problems with Clang, please file bugs!
        The NDK will not be upgrading to 5.x, nor will we be accepting non-critical backports.
        Maintenance for miscompiles and internal compiler errors in 4.9 will be handled on a case by case basis.
    GCC 4.8 has been removed. All targets now use GCC 4.9.




EBC, The EFI Byte Code, is a UEFI feature that supports Intel (Itanium, x86, and x64) instructions in a single bytecode. The Intel C Compiler can target EBC, and UEFI drivers can use EBC instead of native drivers, to save space (1 binary, instead of 3).

The other week I gave a firmware security tools talk at BlackLodgeResearch.org, and Vincent Zimmer of Intel showed up. I had a slide complaining that EBC is only supported by Intel C Compiler, a commercial-only product, and that the UEFI Forum should fund a ‘summer-of-code’-style effort to get EBC into GCC or LLVM CLang. After the talk, Vincent mentioned that ICC had to do a bit of unexpected work to generate EBC, and would blog about it. Well, he did blog about it, a few days ago, just catching up to it, and describe the problem.

If you know of someone on the LLVM CLang or GCC project, please try to add a request for EBC support.

Not only would it be nice to have LLVM CLang work with EBC to have an alternative to ICC, and for LLBVM’s Klee fuzzer (to fuzz UEFI via OVMF), but ALSO because the Capstone Framework RE tool uses LLVM’s intermediate form and would then get EBC support!!

Today, radare2, another RE tool, already has EBC support.

If technically possible, it might be nice if ARM added AArch32 and AArch64 support, and EBC support in their compiler, so that EBC could actually target all UEFI platforms with a single blob. ARM/Linaro already has something that appears to overlap in some ways:

Also, there’s a C#/IL to EBC translation project on Github. If you get it to work, let me know!

ARM update on GCC and Clang compilers

A few days ago, the ARM Software Dev Tools blog posted their 2015Q2 update on their use of Open Source Toolchains. The post talks about ARM changes in GNU GCC as well as LLVM. It appears they’re getting ready to present at GNU Cauldron in August. Look at their blog for more information. They’ve got some YouTube video and presentation slides, as well.

One thing this blog post clarified to me was what codebase ARM’s C compiler was based on: LLVM Clang:

“The commercial toolchain we offer to our customers, ARM Compiler 6, is in fact based on open source clang.”

More Information: