## Bug in polymake 2.10

Discussions on installation issues go here.

Moderator: Moderators

gawrilow
Main Author
Posts: 354
Joined: 25 Dec 2010, 17:40

### Re: Bug in polymake 2.10

Thanks again for the numerous fixes! I've incorporated them all in the current codebase, except for changes in the configuration script. We should first thoroughly check if polymake compiled with clang correctly executes all testcases, how the automatic wrapper compilation works, etc. before we recommend clang for the broad audience. If you feel curious and courageous enough to perform these checks, I should give you the access to the repository, because the unit tests are not part of the distribution tarball. Just let me know by a private E-mail (or personal message in this forum).

Regarding "lacking" multiplication operator: in fact, it is well-defined and GCC compiles it without problems. You can see it in action if you type the following in the polymake shell:

Code: Select all

print 2*unit_matrix<Rational>(3);
Thus it must be a clang bug.

The compiler is expected to find the operator's definition in lib/core/include/internal/operations.h by virtue of the argument-dependent lookup rule, because DiagMatrix is derived from operators::base (via GenericMatrix). Either the lookup implementation is buggy here, or the operator is rejected due to SFINAE rule, because the compiler failes to find the proper instantiation of operations::mul_impl. The suitable specialization is in GenericMatric.h, in the line 2423.

Max
Posts: 10
Joined: 19 Dec 2010, 19:47

### Re: Bug in polymake 2.10

I fully agree that clang should only be "officially" supported if it is known to work (and then, too, one will have to impose restrictions on the version). Hence attached is a stripped down version of my configure patch. It make configure better at distinguishing compilers, and in particular explicitly rejects clang. Note that Apple clang 3.0 pretends to be gcc 4.2, and so *without* this patch, one can actually (start to) compile polymake using clang. So if you are concerned about people building polymake with clang, then you should perhaps apply something like this patch, otherwise nothing stops them from (or even warns them about) doing it. This patch will also reject unknown compilers as "unsupported" instead of "this gcc version is too old".

Great to hear that you have unit tests, I wish more projects did. Although I am a bit surprised to learn that they are not public. Are there specific reasons for that? (Maybe they are very difficult to use, or contain "private" data?) It would seem natural to me to ship them to users, so that they can verify their installation is correct, by running a test script (GMP, GAP and other projects do just that). Considering that there are so many versions of GCC out there (not to forget about the different platforms & architectures as well as vendor patches), I'd not be surprised if some of these also miscompile polymake. And then there is ICC and its versions and variations... well, and of course crazy people like me who try to compile with clang .

BTW, the main reason I am looking at compiling polymake with clang is (a) the improved diagnostics, with which I helped Silke to track down a bug in her polymake code a couple months ago, and (b) the fact that Apple is switching to clang as the primary compiler, and so Fink is currently working on adapting to that... I updated to XCode 4.2 a couple days ago and now am testing all kinds of stuff with clang. Indeed, I think clang support will become more and more relevant, and beyond that it offers some compelling benefits (like those compiler warnings that are so much more human readable, that GCC's look like a bad joke in comparison). So I hope it'll eventually be possible to compile polymake (and GAP, Singular, and anything, really) with it.

Thanks for the hints on the matrix multiplication, I'll take another look at the code! And I did not doubt polymake can multiply matrices by scalars, only the mechanism for that was/is not clear to me. And of course that GCC compiles sadly does not mean that the code is valid C++, hence my question .
Attachments
polymake-compiler-detection.patch
Enhance compiler detection

gawrilow
Main Author
Posts: 354
Joined: 25 Dec 2010, 17:40

### Re: Bug in polymake 2.10

Unit tests are not private, they are just too many to be bundled together with a source distribution. Surely we ought to publish them, it would just incur some additional administrative overhead, e.g. they also need to be branched off with each public release, and we are so short on HR... The final call: would you like to get an access to our repo?

Regarding clang, it would be great to make polymake compatible with it, the error diagnostics are without doubts awesome. Do you know about some benchmarks of optimized code produced by clang vs. gcc, especially for "polymake-like" code with very few floating point arithmetic but much scattered memory access?