Remarks without numbers

[SKost]

I detected a case when some Intel C++ compilerremarks are displayed without numbers. Please take a look on a generic form:

..\\.cpp(nnn): (col. 1) remark: ?@ has been targeted for automatic cpu dispatch.

Ascreenshot will be provided.

Here is a real example:

------ Build started: Project: IccTestApp, Configuration: Release Win32 ------
Compiling with Intel C++ Compiler XE 12.1.3.300 [IA-32]... (Intel C++ Environment)
icl: command line warning #10121: overriding '/EHs' with '/EHs-'
Stdphf.cpp
C:\\WorkEnv\\AppsWorkDev.R&D\\AppsSca\\ScaLib\\DataSet.cpp(132): (col. 1) remark: ?RunAlgorithm@CDataSet@@UAEEXZ has been targeted for automatic cpu dispatch.
C:\\WorkEnv\\AppsWorkDev.R&D\\AppsSca\\ScaLib\\MatrixSet.cpp(514): (col. 2) remark: ?MulHelper@?$TStrassenHBISet@M$02@@QAEXPAPAM00I@Z has been targeted for automatic cpu dispatch.
C:\\WorkEnv\\AppsWorkDev.R&D\\AppsSca\\ScaLib\\MatrixSet.cpp(612): (col. 2) remark: ?Add@?$TStrassenHBISet@M$02@@QAEXPAPAM00I@Z has been targeted for automatic cpu dispatch.
...
Compiling with Intel C++ Compiler XE 12.1.3.300 [IA-32]... (Intel C++ Environment)
icl: command line warning #10121: overriding '/EHs' with '/EHs-'
IccTestApp.cpp
Linking... (Intel C++ Environment)
xilink: executing 'link'
Creating library ..\\Release\\IccTestApp.lib and object ..\\IccTestApp\\Release\\IccTestApp.exp
Embedding manifest... (Microsoft VC++ Environment)
IccTestApp - 0 error(s), 2 warning(s), 3 remark(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

Compileroptions are as follows:

/c /O3 /Ob2 /Oi /Ot /I "..\\..\\Include" /D "WIN32" /D "_CONSOLE" /D "NDEBUG" /D "_WIN32_ICC"
/D "INTEL_SUITE_VERSION=PE121_300" /D "_AFXDLL" /D "_VC80_UPGRADE=0x0710" /D "_UNICODE"
/D "UNICODE" /GF /EHsc /MD /GS- /fp:precise /Yu"Stdphf.h"
/Fp"Release\\IccTestApp.pch" /Fo"Release/" /W5 /nologo /TP /Qdiag-disable:473
/U "_WIN32_MSC" /U "_WIN32CE_MSC" /U "WIN32_PLATFORM_PSPC" /U "WIN32_PLATFORM_WFSP"
/U "WIN32_PLATFORM_WM50" /U "_WIN32_MGW" /U "_WIN32_BCC" /U "_COS16_TCC"
/QaxAVX /Qdiag-disable:111,673 /Zc:wchar_t /Zc:forScope /GR /Zm1000 /EHs-c-

My Development Environment:

OS: Windows XP 32-bit
IDE: Visual Studio 2005 SP1
Compilers: Intel C++ / Microsoft C++ / Borland C++ / MinGW / Turbo C++

Intel C++ compiler version ( Composer XE 2011 Update 9 ):

Intel C++ Compiler XE 12.1.3.300 [IA-32]

Best regards,
Sergey

[SKost]

Here is a screenshot:

[Judith_W_Intel]

Yes these type of diagnostics are emitted by the back end of the compiler and generally have to do with optimizations like loops being vectorized.

Did youhave a particular question or was this just an observation?Like would you expect that the names to be unmangled?

Judy

[SKost]

Quoting Judith Ward (Intel)

...
Yes these type of diagnostics are emitted by the back end of the compiler and generally have to do with optimizations like loops being vectorized.

Did youhave a particular question or was this just an observation?

Yes. I would be glad to seeall remarks with numbers, like:

..\.cpp(nnn): (col. 1) remark 12345: ?@ has been targeted for automatic cpu dispatch.

and then I could disable it with '/Qdiag-disable:12345'. Please consider this as a feature request.

Like would you expect that the names to be unmangled?

No. Yes

Judy

Thank you, Judy!

Best regards,
Sergey

[Updated]

[SKost]

Quoting Judith Ward (Intel)

...
Like would you expect that the names to be unmangled?

I'd like to change my previous answer from No to Yes. That is, unmangled form will look better:

A generic form for a class:

..\.cpp(nnn):remark #nnnn: :: has been targeted for automatic cpu dispatch.

A real example for a class:

...\DataSet.cpp(132): remark #12345: CDataSet::RunAlgorithm has been targeted for automatic cpu dispatch.

[ILevi1]

I second this idea. It would be usefull to have unmangled names.

I thought that you can already disable those remarks?

[SKost]

Hi Igor,

Quoting Igor Levicki

I second this idea. It would be usefull to have unmangled names.

I thought that you can already disable those remarks?

Unfortunately No because it doesn't have a number. ( I used '12345' as an example! )

I've done additional investigation and acompiler option /QaxAVX is the source of the remark.

Best regards,
Sergey

[SKost]

Here is another set of Intel C++ compilerremarks without numbers:

...remark: PARTIAL LOOP WAS VECTORIZED.
...remark: loop was not vectorized: existence of vector dependence.
...remark: loop was not vectorized: notinner loop.
...remark: loop was not vectorized: nonstandard loop is not a vectorization candidate.
...remark: loop skipped: multiversioned.

[ILevi1]

Sergey, those remarks should not be output unless you use /Qvec_report switch with n > 0.

[SKost]

Quoting Igor Levicki

Sergey, those remarks should not be output unless you use /Qvec_report switch with n > 0.

Thanks, Igor. I see that there are three types of different diagnostic messages of Intel C++ compiler:

- warnings with numbers
- remarks with numbers
- remarks without numbers

So, remarks without numberslook like some inconsistency because:

- there are no warnings without numbers
- I can't disableremarks without numberswith a #pragma warning ( disable : nnnn )directive when
they aredisplayed

Also, maybe it makes sense to have a new #pragma remark ( disable : nnnn ) directive? Please consider it
as a feature request.

Best regards,
Sergey

[Om_S_Intel · Accepted solution]

I am planning to submit a feature request to fix the remarks without numbers. It world be nice if you can help with small code segment that produces remarks without numbers.

Thanks,

Om

[ILevi1]

Remarks without numbers are output by compiler diagnostics and they are only output if you enable diagnostics remarks -- they are enabled and disabled as a group.

/Qvec_report:2 will output loop vectorization remarks without numbers. Conversely, if you remove /Qvec_report those remarks won't be output. There is no need for them to have a number when they can be enabled and disabled with a switch -- number doesn't add any value to their content.

I agree that other remarks without number should have it, but I disagree on vectorization and optimization diagnostics remarks.

[SKost]

Quoting Om Sachan (Intel)

I am planning to submit a feature request to fix the remarks without numbers. It world be nice if you can help with small code segment that produces remarks without numbers.

Thanks,

Om

I'll try to create a Test-Case for:

..\.cpp(nnn):remark: @ has been targeted for automatic cpu dispatch.

remark.

[SKost]

Here is a Test-Case:

[cpp] ... // Sub-Test For Intel C++ compiler remark: ?@ has been targeted for automatic cpu dispatch #define _TESTDLL_EXPORTS #ifdef _TESTDLL_EXPORTS #define _TESTAPI _declspec( dllexport ) #else #define _TESTAPI _declspec( dllimport ) #endif class _TESTAPI CBaseObject { public: CBaseObject( void ){}; virtual ~CBaseObject( void ){}; virtual bool Method( void ) { return ( bool )true; }; }; class _TESTAPI CTestObject : public CBaseObject { public: CTestObject( void ){}; virtual ~CTestObject( void ){}; public: virtual bool Method( void ) { return ( bool )true; }; }; ... ... CTestObject to; to.Method(); ... [/cpp]

[SKost]

Any updates on the issue? . >>>>Quoting Judith Ward (Intel) ... >>>>Like would you expect that the names to be unmangled? >> >>I'd like to change my previous answer from No to Yes. That is, unmangled form will look better: >> >>A generic form for a class: >> >>..\.cpp(nnn):remark #nnnn: :: has been targeted for automatic cpu dispatch. >> >>A real example for a class: >> >>...\DataSet.cpp(132): remark #12345: CDataSet::RunAlgorithm has been targeted for automatic cpu dispatch. . I think Microsoft / Intel C/C++ compiler predefined ANSI C macro __FUNCTION__ has to be used instead of __FUNCDNAME__ macro: . When used in a scope of 'CDataSet::RunAlgorithm' method __FUNCDNAME__ "returns" '?RunAlgorithm@CDataSet@@UAEEXZ' . When used in a scope of 'CDataSet::RunAlgorithm' method __FUNCTION__ "returns" 'CDataSet::RunAlgorithm' Best regards, Sergey

[jimdempseyatthecove]

Sergey Kostrov wrote:
Quoting Judith Ward (Intel) ...
Like would you expect that the names to be unmangled?

I'd like to change my previous answer from No to Yes. That is, unmangled form will look better:

A generic form for a class:

..\.cpp(nnn):remark #nnnn: :: has been targeted for automatic cpu dispatch.

A real example for a class:

...\DataSet.cpp(132): remark #12345: CDataSet::RunAlgorithm has been targeted for automatic cpu dispatch.

Judith Consider #pragma remark(disable:"has been targeted for automatic cpu dispatch") Same with warning IOW permit either number or text (where text can be partial match using strstr). Jim Dempsey

[SKost]

>>Consider >> >>#pragma remark(disable:"has been targeted for automatic cpu dispatch") >>Same with warning Unfortunately it doesn't work with Microsoft C/C++ compiler: When #pragma remark( disable : "has been targeted for automatic cpu dispatch" ) used in source codes the compiler outputs: ... ..\prttests.cpp(6594) : warning C4068: unknown pragma ...

[jimdempseyatthecove]

>>prttests.cpp(6594) : warning C4068: unknown pragma Then conditionalize for the compiler(s) supporting the feature. (or disable warning C4068 around the pragma) The point being to get rid of the anoying remark. Jim

[SKost]

>>...Then conditionalize for the compiler(s) supporting the feature. (or disable warning C4068 around the pragma)... Thanks, Jim. I'll try it.

[SKost]

>>...I think Microsoft / Intel C/C++ compiler predefined ANSI C macro __FUNCTION__ has to be used instead of __FUNCDNAME__ macro... I had a couple of issues with __FUNCSIG__, __FUNCDNAME__ and __FUNCTION__ macros when used on a project that was designed and implemented for several platforms. So, here is a piece of codes and I hope it will be useful: [cpp] ... #if ( defined ( _WIN32_MSC ) || defined ( _WIN32_ICC ) ) #define __RTFUNCTION2__( _fname ) __FUNCTION__ #ifdef _RTDEBUG #define __RTFUNCTION( _fname ) CrtPrintfA( "%s\n", __FUNCTION__ ) #else #define __RTFUNCTION( _fname ) #endif #endif #if ( defined ( _WIN32CE_MSC ) ) #define __RTFUNCTION2__( _fname ) __FUNCTIONW__ #ifdef _RTDEBUG #define __RTFUNCTION( _fname ) CrtPrintf( RTU("%s\n"), __FUNCTIONW__ ) #else #define __RTFUNCTION( _fname ) #endif #endif #if ( defined ( _WIN32_MGW ) || defined ( _WIN32_BCC ) || defined ( _COS16_TCC ) ) #define __RTFUNCTION2__( _fname ) _fname #ifdef _RTDEBUG #define __RTFUNCTION( _fname ) CrtPrintfA( "%s\n", __RTFUNCTION2__( _fname ) ) #else #define __RTFUNCTION( _fname ) #endif #endif ... [/cpp]