Blaze examples to create submatrix fail with vs2017 on Windows 10

Issue #212 wontfix
Daniel Parker created an issue

OS: Windows 10 Compiler: vs2017 Blaze version: 3.4

blaze::DynamicMatrix<double, blaze::rowMajor> A(100UL,100UL);

auto sm1 = blaze::submatrix<3UL, 0UL, 4UL, 8UL>(A);

Fails with Error C4146 unary minus operator applied to unsigned type, result still unsigned Tests c:\sites\var\third_party\blaze\math\views\submatrix\dense.h 884

auto sm2 = submatrix( A, 0UL, 4UL, 8UL, 16UL );

Same error

Comments (3)

  1. Klaus Iglberger

    Hi Daniel!

    Thanks for creating this issue. We have taken a close look at the problem, but unfortunately fail to reproduce it. Our entire test suite, including the two examples you use, compiles flawlessly with VS2017. Also, the line that you posted does not directly contain a unary minus operator. Therefore we have to guess which line causes the problem.

    At this point we suspect that the problem is caused by a set of very strict compilation flags. Also, C4146 is only a compiler warning that you apparently treat as error. Could you please also post the compilation flags that you are using? It would also help us if you could post the original error message. Thanks a lot for your help,

    Best regards,

    Klaus!

  2. Klaus Iglberger

    Hi Daniel!

    With no further information about the details of the compilation error we have to continue to assume that it is caused by a set of overly strict compilation flags. We suspect that the compilation error is triggered by code similar to the following expression:

    constexpr size_t SIMDSIZE = ...;  // Assigned a compile-time constant multiple of 2
    constexpr size_t mask = -SIMDSIZE;  // Same as ~SIMDSIZE + 1UL
    

    According to the C++ standard the behavior of applying the unary minus operator to an unsigned integral value is well defined (see expr.unary.op, note 8):

    ... The negative of an unsigned quantity is computed by subtracting its value from 2^n, where n is the number of bits in the promoted operand. The type of the result is the type of the promoted operand.

    Under this assumption, this compilation error does not justify a blocker bug issue. Thus we will not try to resolve the issue.

    Best regards,

    Klaus!

  3. Log in to comment