On Thursday 26 May 2011 12:18:19 Richard Guenther wrote:
> On Thu, May 26, 2011 at 12:06 PM, Matthias Kretz wrote:
> > __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>
>
> How would that help with vendors releasing updates with fixes?
If the vendor releases an update he increases the patchlevel. (So the value of
__GNUC_SUSE_VERSION__ would change from 0x110400 to 0x110401 with an update to
the 11.4 GCC package.) Thus, there is a possiblity for the code to
differntiate between the different GCC releases.
Obviously, the library developer can only "fix" things when he checks a given
release (or if he receives a patch/hint by somebody else). The way I do it
with GCC workarounds is that if I discover a problem with a given release I
will only add a workaround for this one version, report a bug for that branch
and expect the next GCC release to be fixed. I then monitor that bug report
and the upcoming release. If the release is not going to fix the bug I add the
next GCC version to the list of versions that require the workaround.
> 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.
And? Because they are rare we shouldn't care? I'm developing a template
library for SSE, AVX, LRBni, ... and this stuff is like daily bread for me. So
I'm surely a special GCC user here...
But this SIMD stuff is hard to understand and my library is supposed to make
it easier for average developers. I think my API reaches that goal, but
compiler availability and compiler bugs almost negate that again. So one of my
major goals is to make it just work as good as possible with any given
compiler. It's just plain hard to impossible ATM. This simple macro would be
of major help. At the same time I don't see any downsides, do you?
> > 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.
Yeah, and that's great. But it doesn't help a bit with the problem I'm trying
to solve.
> 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.
Yeah, but in a way any number you put for the patchlevel is wrong, unless you
package an unmodified patch-release. I reality you release something like
4.3.4.1. And then that also isn't helpful information...
> > => 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.
If some vendors don't use it, their GCC packages will be treated as vanilla
GCC releases. So let me rephrase that:
=> The suggested macro would make it possible for library headers to work
with all released GCCs that implement the vendor macro, without additional
work for the library user.
> 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).
What is a safe version in this case:
#ifdef API_VERSION_A
__m128 tmp = x;
#else
__m128i tmp = reinterpret_cast<__m128i &>(x)
#endif
foobar(tmp);
It either compiles or it doesn't, there is no middle ground. The same things
can happen with miscompilations, ICEs, or sorrys.
Yes, I'd prefer a perfect world where these problems don't come up. But I'd
rather be able to release an updated version of my library that can work
around issues of released compilers than release all kinds of different
branches for every different compiler packager.
The situation is currently "very bad" for me. We could change it to "bad". I
don't see a workable solution to reach "good", if you do, let me know.
Cheers,
Matthias
--
Dipl.-Phys. Matthias Kretz
http://compeng.uni-frankfurt.de/?mkretz
SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc
