Remarks without numbers

Remarks without numbers

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

23 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

Here is a screenshot:

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

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]

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 second this idea. It would be usefull to have unmangled names.

I thought that you can already disable those remarks?

Regards,
Igor Levicki

Hi Igor,

Quoting Igor LevickiI 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

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.

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

Regards,
Igor Levicki

Quoting Igor LevickiSergey, those remarks should not be output unless you use /Qvec_report[n] 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

Best Reply

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

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.

Regards,
Igor Levicki

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.

Here is a Test-Case:

	...

	// 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();

	...

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

引文:

Sergey Kostrov 写道:
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

www.quickthreadprogramming.com

>>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
...

>>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

www.quickthreadprogramming.com

>>...Then conditionalize for the compiler(s) supporting the feature. (or disable warning C4068 around the pragma)...

Thanks, Jim. I'll try it.

>>...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:


...

#if ( defined ( _WIN32_MSC ) || defined ( _WIN32_ICC ) )
     #define __RTFUNCTION2__( _fname )               __FUNCTION__
     #ifdef _RTDEBUG

     #define __RTFUNCTION( _fname )                  CrtPrintfA( "%sn", __FUNCTION__ )

     #else

     #define __RTFUNCTION( _fname )

     #endif
#endif
#if ( defined ( _WIN32CE_MSC ) )
     #define __RTFUNCTION2__( _fname )               __FUNCTIONW__
     #ifdef _RTDEBUG

     #define __RTFUNCTION( _fname )                  CrtPrintf( RTU("%sn"), __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( "%sn", __RTFUNCTION2__( _fname ) )

     #else

     #define __RTFUNCTION( _fname )

     #endif
#endif

...

Here are a couple of test-cases:


     // On a Windows Desktop platform

     ...                                                // Prints:

     CrtPrintf( RTU("Test-Case 1.1n") );               //    Test-Case 1.1

     CrtPrintfA( "%sn", __FUNCSIG__ );                 //    void __cdecl RunTest1017(void)

     CrtPrintfA( "%sn", __FUNCDNAME__ );               //    ?RunTest1017@@YAXXZ

     CrtPrintfA( "%sn", __FUNCTION__ );                //    RunTest1017

     CrtPrintf( RTU("%sn"), __FUNCTIONW__ );           //    RunTest1017

     ...
     // On a Windows Mobile platform

     ...                                                // Prints:

     CrtPrintf( RTU("Test-Case 1.2n") );               //    Test-Case 1.2

     CrtPrintf( RTU("%sn"), __FUNCSIG__ );             //    ```````````````

     CrtPrintf( RTU("%sn"), __FUNCDNAME__ );           //    `````````Z%s

     CrtPrintf( RTU("%sn"), __FUNCTION__ );            //    `````7`````````Z%s

     CrtPrintf( RTU("%sn"), __FUNCTIONW__ );           //    RunTest1017

     ...
     // On a Windows Mobile platform

     ...                                                // Prints:

     CrtPrintf( RTU("Test-Case 1.3n") );               //    Test-Case 1.3

     CrtPrintf( RTU("%sn"), CA2W( __FUNCSIG__ ) );     //    void __cdecl RunTest1017(void)

     CrtPrintf( RTU("%sn"), CA2W( __FUNCDNAME__ ) );   //    ?RunTest1017@@YAXXZ

     CrtPrintf( RTU("%sn"), CA2W( __FUNCTION__ ) );    //    RunTest1017

     CrtPrintf( RTU("%sn"), __FUNCTIONW__ );           //    RunTest1017

     ...

Also, you can disable the remark above using /Qdiag-disable:cpu-dispatch:

Q:\hello>icl -W5 -QaxAVX -c math.cpp
Intel(R) C++ Compiler XE for applications running on IA-32, Version 13.0.0.089 Build 20120731
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.

math.cpp
math.cpp(3): remark #1418: external function definition with no prior declaration
void foo(float * x, float * y, float * z, int n) {
^

math.cpp(6): remark #1: last line of file ends without a newline
}
^

Q:\hello\math.cpp(3): (col. 50) remark: ?foo@@YAXPAM00H@Z has been targeted for
automatic cpu dispatch.

Q:\hello>icl -W5 -QaxAVX -Qdiag-disable:cpu-dispatch -c math.cpp
Intel(R) C++ Compiler XE for applications running on IA-32, Version 13.0.0.089 Build 20120731
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.

math.cpp
math.cpp(3): remark #1418: external function definition with no prior declaration
void foo(float * x, float * y, float * z, int n) {
^

math.cpp(6): remark #1: last line of file ends without a newline
}
^

Brandon Hewitt
Technical Consulting Engineer

For 1:1 technical support: http://premier.intel.com

Software Product Support info: http://www.intel.com/software/support

>>Also, you can disable the remark above using /Qdiag-disable:cpu-dispatch...

Thank you, Brandon!

Deixar um comentário

Faça login para adicionar um comentário. Não é membro? Inscreva-se hoje mesmo!