On Thu, May 26, 2011 at 12:06 PM, Matthias Kretz <kr...@compeng.uni-frankfurt.de> wrote: > Hi, > > Abstract :) > =========== > A means to distinguish a patched GCC release from a vanilla GCC > release should be added. This would enable developers to work > around incompatibilities between GCC releases in public header > files. One macro, defined only by the respective distributor, > could uniquely identify the distribution and its version. > > > Problem > ======= > As you're surely aware, most people don't actually use GCC as released by the > FSF (aka. "vanilla GCC") but use the versions as packaged by their > distribution (whether that be Linux, MacOS, or whatever else) (aka. "patched > GCC"). Often these patched GCCs include all patches from the SVN branch > available at the time of packaging + some distribution specific changes. > > This leads to incompatiblities between GCC releases that all identify > themselves with the same version number. The most recent issue, which prompts > this mail, was the AVX maskstore interface change between 4.5.2 and 4.5.3 [1]. > There are other conceivable examples; e.g. I experienced compilation errors > (failed inlining) with Fedora GCC, while the same versions of vanilla GCC > compiled my code just fine. > > Ideally, a software project would be able to use configure checks and feature- > macros to work around those issues, and thus support all (vanilla and patched) > GCC releases. But it's not always that "easy". If the code in question resides > in a public header of a library, the feature-macros would have to be correctly > defined by every project that makes use of them, which is a major problem. > > suggested solution > ================== > GCC should provide (an) additional predefined macro(s) to distinguish a > patched GCC from vanilla GCC. This/These macro(s) should be sufficient to > uniquely identify every released GCC from each other. This must also include > updates to distribution packages, which could fix or introduce a problem. > > Idea: > add the following macro: > __GNUC_DISTRIBUTOR_<name>__ > This macro is defined in releases of GCC that are prepared by entities other > than the FSF. The actual name of the macro depends on the value set by the > packager. A list of known names can be found at <page to be provided>. > This macro expands to a number that uniquely identifies the package. The > actual format of the number is defined by the distributor, but it is > recommended that distributors define the value like this: > <distribution major version> * 0x10000 + <distribution minor version> * 0x100 > + <patchlevel> > > (or call it __GNUC_<name>_VERSION__ ?) > > <name> and the value of the macro would be set by a configure switch to GCC > and would have values like "REDHAT", "UBUNTU", "SUSE", ...
How would that help with vendors releasing updates with fixes? So no, I don't like the idea at all. Use configure-time checks instead. The cases where you have to work around compiler issues in a _header_ file should be very rare. > Rationale > ========= > - We can't expect distributors to only ship vanilla GCC packages (even if I'd > prefer that). > - We can't expect that incompatibilities between GCC releases with the exact > same version number will never occur again. > - We can't expect software developers to correctly define compiler-specific > feature-macros for the header files of the libraries they use. > - A means to distinguish different releases of a given GCC version is > currently not available. It is. Vendors use (or should use) --with-pkgversion, so you get > gcc --version gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. and yes, we (SUSE) even adjust the patchlevel version of the compiler down to the last released version instead of keeping the next-to-be released version when picking from a release branch (vanilla GCC would say 'gcc 4.3.5 20100927 [gcc-4_3-branch revision 152973]' or similar. > => The suggested macro would make it possible for library headers to work with > all released GCCs, without additional work for the library user. Only if all vendors use it that way. A better solution is to guard those cases in library headers via a library specific define, defaulting to a "safe" version. That then even works for vendors the library implementor does not know about (you can't even enumerate all vendors, so it's really a pointless approach). Richard. > How to go forward > ================= > I'd look into implementing this for GCC 4.7, if you like the idea. Unless, of > course, somebody else prefers to do it instead. :-) > > [1] https://bugs.launchpad.net/bugs/780551 > > Cheers, > Matthias > -- > Dipl.-Phys. Matthias Kretz > http://compeng.uni-frankfurt.de/?mkretz > > SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc >