Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Luke_H_1
Beginner
503 Views

Potential false positive warning from icl 2017 and Armadillo Template Library (v 7.400)

Jump to solution

Hi,

I recently tried compiling the example program included in the Armadillo Template Linear Algebra library (version 7.400) using the 2017 Intel C++ compiler which was recently released. I got a warning message which I passed onto the Armadillo developer and he has confirmed it is a false positive. I can also confirm that the message is not displayed when the same example is compiled using either clang++ (version 3.8.0) or g++ (version 5.3.0) using MinGW-w64. Note, the code does compile and the output produced matches the output from the other two compilers.

My set up is Windows 7 SP1 x64 using Visual Studio 2015 Community Update 3 and compiling via the Intel64 command prompt short cut.

The warning message is below:

example.cpp
C:\Libs\Armadillo\Include\armadillo_bits/arma_ostream_meat.hpp(95): warning #173: floating-point value does not fit in required integral type
          cond_rel< is_non_integral<eT>::value && is_signed<eT>::value >::geq(val, eT(-1e-4))
                                                                                   ^
          detected during:
            instantiation of "std::streamsize={_Longlong={__int64}} arma::arma_ostream::modify_stream(std::ostream &, const eT *, arma::uword={arma::u32={unsigned int}}) [with eT=arma::u32={unsigned int}]" at line 413
            instantiation of "void arma::arma_ostream::print(std::ostream &, const arma::Mat<eT> &, bool) [with eT=arma::u32={unsigned int}]" at line 6031 of "C:\Libs\Armadillo\Include\armadillo_bits/Mat_meat.hpp"
            instantiation of "void arma::Mat<eT>::impl_print(const std::string &) const [with eT=arma::u32={unsigned int}]" at line 37 of "C:\Libs\Armadillo\Include\armadillo_bits/Base_meat.hpp"
            instantiation of "void arma::Base<elem_type, derived>::print(std::string) const [with elem_type=arma::u32={unsigned int}, derived=arma::Mat<arma::u32={unsigned int}>]" at line 129 of "example.cpp"

Microsoft (R) Incremental Linker Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Thanks,

Luke

0 Kudos
1 Solution
Judith_W_Intel
Employee
503 Views

 

I don't think is a false positive -- the diagnostic is correct but may be a little aggressive in some situations.

The difference between the Microsoft compiler and the Intel compiler can be shown with this example:

!% cat f.cpp


int main() {
  unsigned int i = (-1e-4); // Microsoft gives warning with /W2 and higher here
  unsigned int j = unsigned int(-1e-4); // but not here
  return 0;
}
!% icl -c  f.cpp
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Versi
on Mainline Beta Build x
Built Sep 15 2016 11:01:53 by jward4 on JWARD4-DESK1 in D:/workspaces/cfe/dev
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

f.cpp
f.cpp(4): warning #173: floating-point value does not fit in required integral type
    unsigned int i = (-1e-4); // Microsoft gives warning with /W2 and higher here
                     ^

f.cpp(5): warning #173: floating-point value does not fit in required integral type
    unsigned int j = unsigned int(-1e-4); // but not here
                     ^

!% cl -c /W2  f.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

f.cpp
f.cpp(4): warning C4244: 'initializing': conversion from 'double' to 'unsigned int', possible loss of data
!%

So it looks like Microsoft only gives a warning if the conversion is done without an explicit cast and only at /W2 and above levels.

I think it would be a reasonable request for Intel to try to emulate that behavior, at least having an explicit cast suppress the warning behavior. Would this be acceptable?

BTW you can disable the warning with the command line option  /Qdiag-disable:173.

Judy

 

View solution in original post

2 Replies
Judith_W_Intel
Employee
504 Views

 

I don't think is a false positive -- the diagnostic is correct but may be a little aggressive in some situations.

The difference between the Microsoft compiler and the Intel compiler can be shown with this example:

!% cat f.cpp


int main() {
  unsigned int i = (-1e-4); // Microsoft gives warning with /W2 and higher here
  unsigned int j = unsigned int(-1e-4); // but not here
  return 0;
}
!% icl -c  f.cpp
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Versi
on Mainline Beta Build x
Built Sep 15 2016 11:01:53 by jward4 on JWARD4-DESK1 in D:/workspaces/cfe/dev
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

f.cpp
f.cpp(4): warning #173: floating-point value does not fit in required integral type
    unsigned int i = (-1e-4); // Microsoft gives warning with /W2 and higher here
                     ^

f.cpp(5): warning #173: floating-point value does not fit in required integral type
    unsigned int j = unsigned int(-1e-4); // but not here
                     ^

!% cl -c /W2  f.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

f.cpp
f.cpp(4): warning C4244: 'initializing': conversion from 'double' to 'unsigned int', possible loss of data
!%

So it looks like Microsoft only gives a warning if the conversion is done without an explicit cast and only at /W2 and above levels.

I think it would be a reasonable request for Intel to try to emulate that behavior, at least having an explicit cast suppress the warning behavior. Would this be acceptable?

BTW you can disable the warning with the command line option  /Qdiag-disable:173.

Judy

 

View solution in original post

Luke_H_1
Beginner
503 Views

Hi Judy,

Thank you for your reply and for the suggestion to disable that particular warning. I appreciate that.

I do think your suggestion is acceptable and Intel should emulate the same behaviour as Microsoft when using an explicit cast. In that particular situation the programmer is making their intention clear so the compiler should comply.

Thanks,

Luke

Reply