Skip to content

Releases: synthetos/gcc-arm-none-eabi-archive

Arm GNU Toolchain: Version 12.2.Rel1 - December 22, 2022

14 Feb 16:14
@giseburt giseburt
12.2.Rel1
84eece6
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Arm GNU Toolchain: Version 12.2.Rel1 - December 22, 2022 Latest
Latest

Mirror or the 12.2.Rel1 files from ARM since downloads from there are apparently throttled.

Please verify the hash with the original from ARM before usage.

This is release 12.2.Rel1 of Arm GNU Toolchain.

Arm GNU Toolchain releases package pre-built binaries of GNU Toolchain for various Arm targets. These are community supported and come with no warranty. For more information, please visit the arm Developer page.

This release includes bare-metal and Linux toolchains for various hosts, as described in the Host Support section.

Changes since Arm GNU Toolchain 11.3.Rel1

  • Updated GCC to source code based on version 12.2.
  • Updated Binutils to source code based on version 2.39.
  • Updated Glibc to version 2.36.
  • Fixed an issue where the compiler, in the Linux target toolchains, might generate an internal compiler error due to microarchitecture-specific instructions that might be unavailable on certain CPUs.
  • The size of the arm-none-eabi toolchain has been reduced by stripping the debug symbols from libraries and object files.

Known Limitations and Issues

  • In the Linux hosted toolchains, GDB is provided with Python support. In the Windows and macOS hosted toolchains, GDB is provided without Python support.

  • When you decompress the windows packages, the decompression requests permission to overwrite certain files. This is because the files have similar names with different case, which are treated as identical names on a Windows host. You can choose to overwrite the files with identical names.

  • Doing IPA on CMSE generates a linker error: The linker will error out when resulting object file contains a symbol for the clone function with the __acle_se prefix that has a non-local binding. Issue occurs when compiling binaries for M-profile Secure Extensions where the compiler may decide to clone a function with the cmse_nonsecure_entry attribute. Although cloning nonsecure entry functions is legal, as long as the clone is only used inside the secure application, the clone function itself should not be seen as a secure entry point and so it should not have the __acle_se prefix. A possible workaround for this is to add a 'noclone' attribute to functions with the 'cmse_nonsecure_entry'. This will prevent GCC from cloning such functions.

  • GCC can hang or crash if the input source code uses MVE Intrinsics polymorphic variants in a nested form. The depth of nesting that triggers this issue might vary depending on the host machine. This behaviour is observed when nesting 7 times or more on a high-end workstation. On less powerful machines, this behaviour might be observed with fewer levels of nesting. This issue is reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91937

Assets 9
Loading

GNU Arm Embedded Toolchain: 9-2019-q4-major - November 06, 2019

17 Feb 15:14
@giseburt giseburt
9-2019-q4-major
84eece6
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
GNU Arm Embedded Toolchain: 9-2019-q4-major - November 06, 2019

Features:

All GCC 9.2 features, plus latest mainline features.

Known Changes and Issues:

  • Doing IPA on CMSE generates a linker error:
    The linker will error out when resulting object file contains a symbol for the clone function with the __acle_se prefix that has a non-local binding. Issue occurs when compiling binaries for M-profile Secure Extensions where the compiler may decide to clone a function with the cmse_nonsecure_entry attribute. Although cloning nonsecure entry functions is legal, as long as the clone is only used inside the secure application, the clone function itself should not be seen as a secure entry point and so it should not have the __acle_se prefix. A possible work around for this is to add a 'noclone' attribute to functions with the 'cmse_nonsecure_entry'. This will prevent GCC from cloning such functions.

Full Release Notes

EULA

Host Platform+Architecture MD5
Windows 32-bit (win32) 82525522fefbde0b7811263ee8172b10
Linux 64-bit (x86_64-linux) fe0029de4f4ec43cf7008944e34ff8cc
Linux ARM 32-bit (armv7l-linux) e68bb85ca57751a0a756f38b17cb1262
Linux ARM 64-bit (aarch64-linux) 0dfa059aae18fcf7d842e30c525076a4
Mac OS X 64-bit (mac) 241b64f0578db2cf146034fc5bcee3d4
Source dec65fe8c14aae90512310dd5fe88bf1

Bold: Built from source

Assets 8
Loading