#pragma warning push 0

[Matt_Clarkson]

Using the following:

#pragma push 0#include "external_header.hpp"#pragma pop

Results in the error:

main.cpp(49): error #1029: warning level out of range, expected value between 1 and 4
#pragma warning push 0

However, the microsoft compiler allows this disabling all warnings by setting all warning levels to zero.  Is there any plans to support this in the intel compiler?

It is a very useful feature in the microsoft compiler because virtually no external headers pass the highest warning level on the microsoft compiler (even their own Dinkumware stdlib) so disabling all warnings for an external header helps.

I can't seem to get the following to work:

#pragma push#pragma warning disable [0-9]+ {[0-9]+...}#include "external_header.hpp"#pragma pop

[Matt_Clarkson]

The following code works with visual studio 2012 stdlib: #pragma warning disable 981 444 383 1572 864 2415 #pragma warning push #pragma warning disable 304 981 444 383 522 2268 2271 2273 2270 193 811 444 1418 1028 981 1572 864 383 2259 697 2415 #include #pragma warning pop /** * @~english * The binary entry point * @returns Status code */ int main() { #pragma warning push #pragma warning disable 2259 int a = 0ULL; // NOLINT(runtime/int) short b = a; // NOLINT(runtime/int) short c = a; // NOLINT(runtime/int) #pragma warning pop return b + c; } But why do warnings 981 444 383 1572 864 2415 have to be disabled for the whole file?

[Matt_Clarkson]

For example removing the 2415 disable results in: main.cpp C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\xtr1common(29): error #2415: variable "std::_Nil_obj" of static storage duration was declared but never referenced static _Nil _Nil_obj; Code: #pragma warning disable 981 444 383 1572 864 #pragma warning push #pragma warning disable 304 981 444 383 522 2268 2271 2273 2270 193 811 444 1418 1028 981 1572 864 383 2259 697 2415 #include #pragma warning pop /** * @~english * The binary entry point * @returns Status code */ int main() { #pragma warning push #pragma warning disable 2259 int a = 0ULL; // NOLINT(runtime/int) short b = a; // NOLINT(runtime/int) short c = a; // NOLINT(runtime/int) #pragma warning pop return b + c; }

[Judith_W_Intel]

In the case of warning 2415 you don't know until the end of the compilation unit that a variable is never referenced. So that is when the actual diagnostic is issued. Therefore the diagnostic must be disabled at that point. Disabling it around the declaration does not work. What diagnostics do the other numbers correspond to?

[Matt_Clarkson]

These are warnings that if I put them at the end of the file everything is OK. I understand that some of them can only be decided at the end of the compilation unit but some of them seem like they could be decided in place. /* Access control type not specified */ 304 /* Value copied to temporary, reference to temporary used */ 383 /* Destructor is not virtual */ 444 /* Extern inline function referenced but not defined */ 864 /* Operands are evaluated in unspecified order */ 981 /* floating-point equality comparisons are unreliable */ 1572 /* static variable declared but not referenced*/ 2415

[Judith_W_Intel]

Let's take warning 444 for example. Below is a test case. The warning (actually remark) is issued when a derived class has a virtual destructor but the base class has a non virtual destructor. Disabling the diagnostic around the declaration of the derived class works as expected for me, i.e.: // t.cpp struct C { ~C(); }; #pragma warning push #pragma warning disable 444 struct D: public C { // disable warning here virtual ~D(); }; #pragma warning pop struct D2: public C { // but not here virtual ~D2(); }; !% icl -c -W5 t.cpp Intel(R) C++ Compiler XE for applications running on IA-32, Version Mainline Bet a Build x Built Sep 22 2012 23:42:21 by jward4 on JWARD4-DESK in D:/workspaces/cfe/dev Copyright (C) 1985-2012 Intel Corporation. All rights reserved. t.cpp t.cpp(15): remark #444: destructor for base class "C" (declared at line 3) is no t virtual struct D2: public C { ^ Here's another example of warning/remark 981, which also seems to work as expected for me: int i = 0; static int foo(int i,int j) { return i + j;} static int f2(int i) { return i;} int main() { #pragma warning push #pragma warning disable 981 foo(f2(i), f2(i)); // remark 981 is disabled here #pragma warning pop foo(f2(i), f2(i)); // but not here } I already explained the situation with 2415, which is similar to 864 in that the compiler cannot detect the problem until the end of the compilation unit.

[Matt_Clarkson]

Jennifer, Thanks for the information :) Its strange, I wonder why they aren't disabled in the Dinkumware standard library header files. Maybe P.J. Plauger (or one of his colleagues) is doing some #pragma warning(...) that the intel compiler is reading. I've got it cleanly building on Windows now with the Visual Studio 2012 standard library. I had to disable some warnings (and remarks) system wide. We compile with three different compilers across various OSes so most diagnostics will hopefully be caught in different ways. What does 981 actually specify? foo(f2(i), f2(i)); I assume this would solve that warning: int a = f2(i); int b = f2(i); foo(a, b); What is the compiler remarking against here?

[Judith_W_Intel]

The warning numbers for the Intel compiler don't necessarily correspond to the warning number for the Microsoft compiler (we try to correlate them but there's not always a 1:1 correspondence) so unless the Dinkumware libs have been ported to the Intel compiler there are probably ones that are not disabled. As far as remark 985 this it is trying to warn you about expressions that have a potential observable side effect and that the standard does not guarantee will be issued in any specific order. For example, when there's an argument list to a function call there is no guarantee which argument will be evaluated first. So yes the changes you mention would solve that remark. Observable side effects include I/O operations, accesses to volatile objects, and calls (which may do either of those things).

[Matt_Clarkson]

Thanks Judith - sorry for getting your name wrong in the last post :-( It is good information about the standard - I didn't know that it was not specified the evaluation order.