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
![Wink ;)](./images/smilies/icon_e_wink.gif)
.
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.
![Smile :)](./images/smilies/icon_e_smile.gif)
And of course that GCC compiles sadly does not mean that the code is valid C++, hence my question
![Wink ;)](./images/smilies/icon_e_wink.gif)
.