On 7/7/17, Jeff Law <l...@redhat.com> wrote: > 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 >
gcc sources themselves have tests for attribute availability based on gcc version number; see include/ansidecl.h: https://gcc.gnu.org/viewcvs/gcc/trunk/include/ansidecl.h?revision=248205&view=markup (this is instead of doing things the autoconf way)
