GMP and clang bugginess
tg at gmplib.org
Mon May 25 08:45:46 UTC 2015
nisse at lysator.liu.se (Niels Möller) writes:
I think that requiring an --enable-clang to be able to build with any
version of clang on any platform whatsoever is a bit harsh.
Harsh against whom? The point is not to make a statement, but to make
it more likely that GMP works correctly for our users.
On the other
hand, a blacklisting of known broken compilers (by version and where
relevant also by platform), and a --disable-compiler-blacklist option to
override it, would be helpful to both users and us.
This would be great, but it is a significant burden to maintain.
And, let's say that clang 3.4 works for compiling GMP on x86-64 except
when passed -mtune=foo and -mtune=bar. Blacklisted or not? I suggest
that this is the situation for x86. Of course, we may define any
granularity here, with corresponding maintenance cost.
If a user has the latest and greatest clang on a very vanilla x86 system
where it actually works fine, the user is going to be pretty annoyed by
an --enable-clang option, and possibly make it a habit to always use
I suppose I need to make my point clearer by enabling broader clang
testing; I doubt there exist a clang release which does not miscompile
GMP for some -mtune= option...
Ideally, the blacklist in configure should automatically turn red
entries to orange on the list of test results. And unexpected successes
with a blacklisted compiler could also be marked in some happy color
distinct from the usual green.
The former is perhaps not so easy, the latter is simple. Light
It would also be useful to have an overview of known compiler issues
somewhere on the web-page, and a pointer to that info in the
bug-reporting chapter in the manual. A bit like the freebsd problems
listed in recent NEWS.
I think this has limited value. It will also tend to become a list of
obsolete issues, unless we remember to maintain it. We need to keep in
mind that of the users that compile GMP from source, very few will do
anything but "configure; make; sudo make install".
How often do you yourself scan a manual for build problems before
building a package? :-)
> BTW, it would be nice with an alternative test result page with
> problematic platforms only, or sorted with failing platforms at the top.
> Not sure what you mean. Just problematic confs, with the problematic
> confs on top? Or do you mean to put clang test results on a separate
Either some way to sort the current list so that builds with problems
are at the top, followed by the all-green entries.
Or a separate page, where the all-green entries are omitted.
With the current list, quite a lot of scrolling is needed to identify
the set of failed builds.
I'll see what I can do...
Please encrypt, key id 0xC8601622
More information about the gmp-devel