Re: how to distinguish patched GCCs

[Richard Guenther <richard dot guenther at gmail dot com>]

On Thu, May 26, 2011 at 12:06 PM, Matthias Kretz
<kretz@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
>