Re: Bug in polymake 2.10
Posted: 02 Nov 2011, 00:17
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: 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.
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);
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.