Release naming convention should include patch number

[Richard Lang]

As per the root GCC (https://gcc.gnu.org/) so that we can see directly what patch level a release is at, rather than having to count the number of preceding quarterly updates

[Thomas Preud'homme (thomas-preudhomme)]

Hi Richard,

We base our release on the stable SVN branch of GCC, not on the tarball. Therefore, a given release would usually be the last patch release + some other fixes not part of any release yet + some ARM specific changes. We will think about that but one thing to consider is that people might think we only have the fixes up to the latest patch release while we actually have more fixes than that.

Best regards,

[Richard Lang (r-e-lang)]

I had troubles when I installed the latest release (4.9-2015-q3-update) to rebuild a project that had last been worked on several months back with a previous release of the toolchain, and discovered that stdlib now included an atoi() implementation that collided with a custom implementation in our source.

I set about trying to place a conditional compilation wrapper around our custom implementation based on the __GNUC__, __GNUC_MINOR__ & __GNUC_PATCHLEVEL__ macros, and not being able to figure out what the macro values would be for any particular release without actually installing it made things quite difficult.

thanks,

Richard.

[Przemyslaw Wirkus (wirkus)]

GCC includes revision number with --version CLI option:

$ gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]