On 07/06/2017 07:25 AM, Daniel P. Berrange wrote: > There are several hundred named attribute keys that have been > introduced over many GCC releases. Applications typically need > to be compilable with multiple GCC versions, so it is important > for developers to know when GCC introduced support for each > attribute. > > This augments the texi docs that list attribute keys with > a note of what version introduced the feature. The version > information was obtained through archaeology of the GCC source > repository release tags, back to gcc-4_0_0-release. For > attributes added in 4.0.0 or later, an explicit version will > be noted. Any attribute that predates 4.0.0 will simply note > that it has existed prior to 4.0.0. It is thought there is > little need to go further back in time than 4.0.0 since few, > if any, apps will still be using such old compiler versions. > > Where a named attribute can be used in many contexts (ie the > 'visibility' attribute can be used for both functions or > variables), it was assumed that the attribute was supported > in all use contexts at the same time. > > Future patches that add new attributes to GCC should be > required to follow this new practice, by documenting the > version. Keying on version #s is generally a terrible way to make your code portable. It's easy to get wrong and due to backporting there's not always a strong tie between a version number and the existence of a particular feature.
It's far better to actually *test* what your particular compiler compiler supports. I suspect autoconf, for example, probably has some infrastructure for testing if specific attributes are supported by the compiler. Jeff
